Add Windows Hub UI for gateway session maintenance settings

[clawsweeper]

Problem

Windows Hub exposes the gateway's sessions list and a generic configuration editor, but it does not provide a dedicated UI for managing session.maintenance settings such as mode, pruneAfter, maxEntries, resetArchiveRetention, maxDiskBytes, and highWaterBytes.

Operators using Windows Hub should not need to edit raw gateway configuration to control session retention and disk usage.

Proposed UI

Add a Session maintenance section to the existing Gateway Configuration page that:

• loads the current session.maintenance values from the connected gateway
• exposes the supported settings with defaults and concise explanations
• saves the full updated config through config.patch with optimistic concurrency
• preserves unrelated gateway configuration
• clearly handles disconnected, read-only, loading, validation, conflict, and save-result states

Acceptance criteria

• Windows Hub can view and update all supported session.maintenance settings.
• Omitted values display gateway defaults without unnecessarily materializing them until the user saves.
• Numeric and duration/disk-size inputs are validated before saving.
• Changes participate in the Configuration page's existing Save/Discard flow, preserve unrelated config, and refresh the gateway snapshot.
• Focused model/UI contract tests cover parsing, validation, patch construction, and the Sessions page surface.
• Current-head UI proof is attached, or an explicit Windows-host blocker is documented.

Upstream reference: docs/reference/session-management-compaction.md in openclaw/openclaw.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 15, 2026, 8:13 AM ET / 12:13 UTC.

Summary
Keep this open: it is a new, bounded Windows Hub UX request with an open linked implementation PR, so it should remain canonical until maintainers choose the product direction and the PR is reviewed.

Reproducibility: not applicable. as a bug reproduction. Current source confirms that the dedicated surface is absent, while the existing schema-guided configuration editor is available.

Root-cause cluster
Relationship: canonical
Canonical: #1161
Summary: The open linked PR is a candidate implementation for this feature request, not a merged resolution.

Members:

• fixed_by_candidate: feat: add gateway session maintenance settings UI #1162 - Its body explicitly declares that it closes this issue, but it remains open and lacks Windows-host real-behavior proof.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.
• Include redacted logs or terminal output.

Maintainer decision needed

Question	Recommendation
Should Windows Hub maintain a typed Session maintenance editor alongside the existing schema-guided gateway configuration editor?	Keep the schema-guided editor: Decline the parallel typed surface and rely on the existing gateway-schema form for session-maintenance changes.

Why: Current main already supports schema-driven configuration edits, while the requested typed field set and defaults are gateway-owned; choosing a parallel maintained UI is a product and compatibility commitment.

Next step
The linked open PR already owns implementation, while maintainers must first decide whether a parallel typed editor is a supported product contract.

Review details

Best possible solution:

Keep the schema-guided editor as the compatibility baseline, and land a typed session-maintenance surface only after maintainers explicitly sponsor its upstream-contract ownership and a Windows gateway save/refresh proof is supplied.

Do we have a high-confidence way to reproduce the issue?

Not applicable as a bug reproduction. Current source confirms that the dedicated surface is absent, while the existing schema-guided configuration editor is available.

Is this the best way to solve the issue?

Unclear. A typed editor may improve usability, but the generic schema-driven editor already provides an editing path, so maintainers must first decide whether the parallel surface is worth its upstream compatibility cost.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• A typed editor would duplicate part of the existing schema-guided editor unless maintainers commit to owning its field set, labels, defaults, and compatibility behavior.
• The requested field contract is owned by the gateway upstream, so a fixed Windows UI must remain compatible with gateway schema and default changes.
• The linked PR reports no Windows-host live save round-trip or visible current-head proof, which remains necessary before merge.

Codex review notes: model internal, reasoning high; reviewed against fc9add75eda7.

Label changes

Label changes:

• add clawsweeper:linked-pr-open: Current issue advisory state selects this label.

Label justifications:

• P3: This is a low-urgency, optional UX enhancement rather than a broken established behavior.
• impact:ux-friction: A dedicated view could reduce operator friction for a narrowly scoped group of gateway settings, while the generic editor remains available.

Evidence reviewed

What I checked:

• Current configuration workflow: Current main already provides a schema-guided gateway configuration editor rather than requiring raw-file editing. (src/OpenClaw.Tray.WinUI/Pages/ConfigPage.xaml:29, fc9add75eda7)
• Safe existing save path: The page requests both schema and config, then applies staged changes to the snapshot and sends config.patch with the snapshot base hash. (src/OpenClaw.Tray.WinUI/Pages/ConfigPage.xaml.cs:646, fc9add75eda7)
• Unrelated configuration preservation: The current model copies the gateway JSON and overlays only changed dot-paths; its test covers preserving unrelated configuration. (tests/OpenClaw.Tray.Tests/ConfigEditorModelTests.cs:33, fc9add75eda7)
• No dedicated surface on main: A current-tree search found no session.maintenance-specific UI or model; the Sessions page is a session list with per-session actions, not a maintenance-settings editor. (src/OpenClaw.Tray.WinUI/Pages/SessionsPage.xaml:13, fc9add75eda7)
• Open implementation candidate: The provided GitHub context identifies feat: add gateway session maintenance settings UI #1162 as open and explicitly linked to close this issue, so this issue should not close before that PR merges. (8445db12abaa)
• Feature-history provenance: The config editor overhaul appears to date to the ConfigPage revamp commit, making its author a relevant routing candidate. (src/OpenClaw.Tray.WinUI/Pages/ConfigPage.xaml.cs:23, 9de9b5ba0f8a)

Likely related people:

• Ranjesh: Authored the directly named ConfigPage editor revamp, the existing workflow this proposal would extend. (role: feature-history contributor; confidence: medium; commits: 9de9b5ba0f8a; files: src/OpenClaw.Tray.WinUI/Pages/ConfigPage.xaml, src/OpenClaw.Tray.WinUI/Pages/ConfigPage.xaml.cs)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.