feat: add gateway session maintenance settings UI

[clawsweeper]

Summary

• add a dedicated Session maintenance expander to the existing Gateway Configuration page
• expose mode, pruneAfter, maxEntries, resetArchiveRetention, maxDiskBytes, and highWaterBytes
• stage edits through the page's existing Save/Discard, validation, JSON preview, and optimistic config.patch flow
• reset drafts when the active gateway client changes so values cannot leak between gateways
• add parser/model coverage, UI source-contract coverage, and localized resource plumbing

Fixes #1161

Validation

• git diff --check - passed
• XML parse for ConfigPage.xaml and all Resources.resw files - passed
• resource-key parity for all five locales - passed
• ./build.ps1 - blocked on this Linux host (pwsh is unavailable; direct execution is not supported)
• dotnet test ./tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj --no-restore - blocked (dotnet is unavailable)
• dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore - blocked (dotnet is unavailable)

Rubber-duck review identified and drove fixes for cross-gateway stale drafts, refresh-overwriting edits, gateway parser parity, archive-retention wording, and localization coverage.

Real behavior proof

Not verified / blocked: this host is Linux and cannot launch the WinUI app. The changed state is covered by source-contract tests, but a current-head Windows screenshot and live save round-trip still need Windows CI or maintainer proof.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

[clawsweeper]

Codex review: needs real behavior proof before merge. Reviewed August 15, 2026, 8:14 AM ET / 12:14 UTC.

ClawSweeper review

What this changes

This PR adds a dedicated Session maintenance editor to the Gateway Configuration page and stages its values through the existing configuration patch flow.

Merge readiness

⛔ Blocked until real behavior proof is added - 8 items remain

Keep open for product-direction review. Current Windows Hub already provides a schema-driven editor for nested gateway configuration, so this second editor needs a concrete approved UX gap; current-head Windows save/reload proof is also missing. Likely related person: Ranjesh (high confidence).

Priority: P3
Reviewed head: 8445db12abaad875f3b1c159d89d68d46310333f
Owner decision: Required. See Decision needed.

Review scores

Measure	Result	What it means
Overall readiness	🧂 unranked krab (1/6)	The patch has focused tests, but it adds an unapproved parallel configuration path and lacks real behavior proof.
Proof confidence	🧂 unranked krab (1/6)	Needs real behavior proof before merge: The PR body states that no current-head Windows screenshot or live gateway save round-trip has been collected. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
Patch quality	🦪 silver shellfish (2/6)	1 actionable review finding remain.

Verification

Check	Result	Evidence
Real behavior	Needs proof	Needs real behavior proof before merge: The PR body states that no current-head Windows screenshot or live gateway save round-trip has been collected. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
Evidence reviewed	5 items	Existing editable configuration path: Current main creates a SchemaConfigEditor for object-valued gateway configuration sections and wires its changes into the existing save flow. Gateway schema behavior: The existing editor renders nested object properties from the gateway-provided schema and falls back to editable configuration objects when needed. Current configuration-editor provenance: The current ConfigPage editing path dates to the configuration-editor revamp and is a shipped main-branch behavior.
Findings	1 actionable finding	[P1] Avoid a second editor for gateway-owned settings
Security	None	None.

How this fits together

Windows Hub obtains a configuration schema and current values from the connected gateway, then lets operators stage and save edits through an optimistic configuration patch. This PR adds a fixed editor for session retention and disk-cleanup settings alongside the existing schema-driven editor.

flowchart LR
A[Gateway configuration schema] --> B[Configuration page]
B --> C[Existing schema-driven editor]
B --> D[New session maintenance editor]
C --> E[Save and validation]
D --> E
E --> F[Gateway configuration patch]

Loading

Decision needed

Question	Recommendation
Should Windows Hub maintain a separate Session maintenance editor when the existing gateway-schema editor already renders nested configuration objects?	Keep the schema-driven editor: Retain the existing generic editor as the sole editing path unless a demonstrated operator workflow cannot be served there.

Why: Choosing a second, hard-coded editing surface determines product UX and an ongoing compatibility policy with gateway schema changes; source review cannot establish that preference.

Before merge

• Add real behavior proof - Needs real behavior proof before merge: The PR body states that no current-head Windows screenshot or live gateway save round-trip has been collected. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
• Avoid a second editor for gateway-owned settings (P1) - The Config page already renders nested gateway configuration from its returned schema. This expander duplicates field definitions, defaults, and validation, creating two editing paths that can drift as the gateway schema changes. Remove it unless a maintainer approves a concrete gap in the existing editor.
• Resolve merge risk (P1) - The gateway-owned schema can evolve independently, while the new hard-coded controls and validators can become a conflicting configuration path.
• Resolve merge risk (P1) - The PR has no current-head Windows proof showing a real gateway load, save, and refreshed session-maintenance values.
• Complete next step (P2) - A maintainer must decide whether the existing schema-driven editor is inadequate before any mechanical repair can be safely defined.
• Improve patch quality - Obtain maintainer direction on whether the schema-driven editor is insufficient.
• Improve patch quality - Attach a redacted Windows proof showing configuration load, save, and refreshed values from a real gateway.

Findings

• [P1] Avoid a second editor for gateway-owned settings — src/OpenClaw.Tray.WinUI/Pages/ConfigPage.xaml:88-90

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Implementation versus tests	production +563, tests +146 across 12 files	The feature adds a substantial parallel configuration surface, making the existing schema-driven path and compatibility rationale important before merge.

Root-cause cluster

Relationship: fixed_by_candidate
Canonical: #1161
Summary: This PR directly attempts the linked feature request, but whether the dedicated editor should exist remains a maintainer product decision.

Members:

• canonical: Add Windows Hub UI for gateway session maintenance settings #1161 - The PR explicitly implements the issue's requested Session maintenance editing surface.

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

Merge-risk options

Maintainer options:

1. Keep one schema-driven editing path (recommended)
   Do not merge the parallel editor unless its supported workflow is shown to be unavailable through the existing schema-driven configuration page.
2. Define and prove the specialized path
   If sponsoring this UI, document its gateway-schema compatibility boundary and attach a current-head Windows load, save, and refresh proof before merge.

Technical review

Best possible solution:

Keep one gateway-schema-driven configuration editor unless a maintainer explicitly sponsors a specialized experience with documented gateway-version behavior and direct Windows save/reload proof.

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

Not applicable: this PR proposes a new editing surface rather than reporting a failing behavior. A Windows live save/reload remains required merge proof.

Is this the best way to solve the issue?

No: current main already exposes nested gateway configuration through its schema-driven editor, so a separate fixed editor needs maintainer-approved evidence of a specific UX gap.

Full review comments:

• [P1] Avoid a second editor for gateway-owned settings — src/OpenClaw.Tray.WinUI/Pages/ConfigPage.xaml:88-90
  The Config page already renders nested gateway configuration from its returned schema. This expander duplicates field definitions, defaults, and validation, creating two editing paths that can drift as the gateway schema changes. Remove it unless a maintainer approves a concrete gap in the existing editor.
  Confidence: 0.91

Overall correctness: patch is incorrect
Overall confidence: 0.88

AGENTS.md: found and applied where relevant.

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

Labels

Label changes:

• add P3: This is a proposed configuration UX feature, not a confirmed regression in established behavior.
• add merge-risk: 🚨 compatibility: The fixed controls duplicate gateway-schema-owned fields, defaults, and validation that may change independently across gateway versions.
• add rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🦪 silver shellfish.
• add status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The PR body states that no current-head Windows screenshot or live gateway save round-trip has been collected. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Label justifications:

• P3: This is a proposed configuration UX feature, not a confirmed regression in established behavior.
• merge-risk: 🚨 compatibility: The fixed controls duplicate gateway-schema-owned fields, defaults, and validation that may change independently across gateway versions.
• rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🦪 silver shellfish.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The PR body states that no current-head Windows screenshot or live gateway save round-trip has been collected. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Evidence

What I checked:

• Existing editable configuration path: Current main creates a SchemaConfigEditor for object-valued gateway configuration sections and wires its changes into the existing save flow. (src/OpenClaw.Tray.WinUI/Pages/ConfigPage.xaml.cs:428, fc9add75eda7)
• Gateway schema behavior: The existing editor renders nested object properties from the gateway-provided schema and falls back to editable configuration objects when needed. (src/OpenClaw.Tray.WinUI/Controls/SchemaConfigEditor.xaml.cs:49, fc9add75eda7)
• Current configuration-editor provenance: The current ConfigPage editing path dates to the configuration-editor revamp and is a shipped main-branch behavior. (src/OpenClaw.Tray.WinUI/Pages/ConfigPage.xaml.cs:430, 9de9b5ba0f8a)
• Branch scope: The branch adds a parallel Session maintenance expander and hard-coded field handling rather than extending the schema-driven editor. (src/OpenClaw.Tray.WinUI/Pages/ConfigPage.xaml:88, 8445db12abaa)
• Release provenance: The current main commit containing the generic configuration path is included in the latest local release tag v2026.7.1. (src/OpenClaw.Tray.WinUI/Pages/ConfigPage.xaml.cs:428, fc9add75eda7)

Likely related people:

• Ranjesh: Authored the configuration-editor revamp that established the current ConfigPage editing flow. (role: introduced current configuration editor; confidence: high; commits: 9de9b5ba0f8a, 429be9ba9368; files: src/OpenClaw.Tray.WinUI/Pages/ConfigPage.xaml.cs, src/OpenClaw.Tray.WinUI/Controls/SchemaConfigEditor.xaml.cs)

Rating scale

Score	Internal tier	Crab rank	Meaning
6/6	S	🦀 challenger crab	Exceptional readiness
5/6	A	🦞 diamond lobster	Very strong readiness
4/6	B	🐚 platinum hermit	Good normal PR; ordinary maintainer review
3/6	C	🦐 gold shrimp	Useful, but confidence is limited
2/6	D	🦪 silver shellfish	Proof or implementation needs work
1/6	F	🧂 unranked krab	Not merge-ready
N/A	NA	🌊 off-meta tidepool	Rating does not apply

Overall follows the weaker of proof and patch quality.
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

Workflow

• 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.