Repository navigation
fix(ui): acknowledge successful remote config open - #138757
Conversation
|
🦞👀 Pull request received. I will update this pull request when review starts. ClawSweeper review completeClawSweeper finished reviewing this revision. The review result is being finalized. |
|
Codex review: needs maintainer review before merge. Reviewed September 5, 2026, 1:51 PM ET / 17:51 UTC. ClawSweeper reviewWhat this changesThe Control UI adds a localized confirmation when the Gateway opens its configuration file, with browser coverage for successful responses. Merge readiness✅ Ready for maintainer review The feedback gap remains on current main and v2026.9.1, and this PR provides a focused, useful repair. No blocking correctness or security findings. Priority: P2 Review scores
Verification
How this fits togetherSettings and Memory Wiki send configuration-opening requests through the same Control UI handler. The Gateway opens its host-side file and returns an outcome that the browser presents to the operator. flowchart LR
A[Settings Open] --> C[Shared configuration handler]
B[Memory Wiki enablement] --> C
C --> D[Gateway host file opener]
D --> E{Request outcome}
E -->|Success| F[Browser confirmation]
E -->|Failure| G[Error and file-path fallback]
Before mergeNone. Agent review detailsSecurityNone. PR surfaceSource +4, Tests +28. Total +32 across 3 files. View PR surface stats
Review metrics
Root-cause clusterRelationship: Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Technical reviewBest possible solution: All config-opening entry points should acknowledge the Gateway-host outcome through the shared toast and translation machinery. Do we have a high-confidence way to reproduce the issue? Yes, from source: a successful config.openFile response reaches the end of the current-main handler without browser feedback. The reported host logs and inspected before/after images corroborate that path; this review did not execute it. Is this the best way to solve the issue? Yes. Repairing the shared response handler covers Settings and Memory Wiki together; a page-specific toast would duplicate outcome handling, while changing navigation would alter the existing action. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 3e4becea5e2c. LabelsLabel justifications:
EvidenceWhat I checked:
Likely related people:
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
HistoryReview history (3 earlier review cycles) |
|
CI triage on head |
|
CI repair pushed in |
|
Thanks @VasuBansal7576. The shared fix now uses the existing translation catalog, and its browser test checks the full host explanation and clipboard privacy. Real before/after proof is in the PR body. Both Memory Wiki How to enable and Config Open were driven from a separate browser against a real Gateway desktop. Baseline Focused validation commands: Independent source-blind acceptance passes all eight behavior clauses, including native clipboard contents and pending success/failure across connection replacement. All 58 focused tests pass on the candidate. The success regression fails on baseline while both existing failure cases pass. Focused lint, style checks, pinned formatting, and the combined runtime/UI build pass. CI: https://github.com/openclaw/openclaw/actions/runs/33981907550. @clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. |
|
🦞👀 Re-review progress:
|
|
Thanks @VasuBansal7576! Merged in 7af054e. Proof: Both Memory Wiki How to enable and Config Open now acknowledge a real configuration-file open on the Gateway host, from a separate browser. Success stays path-free and leaves the clipboard unchanged. Rejection retains the exact copied path, and closed connections produce no stale result.
Reviewed source: a81de76. Real before/after screenshots and commands are in the PR body and proof comment. No CI exception was used. |
Show a translated, path-free acknowledgement when Memory Wiki or Config opens the configuration file on the Gateway host. Keep failure guidance and stale-connection suppression in the shared operation. Verified both real UI actions against a separate Gateway desktop, including repeated opens, rejection and connection loss. Fixes openclaw#138374. Co-authored-by: Ayaan Zaidi <hi@obviy.us>
Closes #138374.
What Problem This Solves
Fixes an issue where remote Control UI users received no feedback after Memory Wiki How to enable or Config Open successfully opened the configuration file on the Gateway computer.
Why This Change Was Made
Both buttons share one operation, so that operation now shows a translated acknowledgement after a successful Gateway response. The message identifies the Gateway host and excludes its file path. Existing failure guidance, clipboard fallback, and connection checks stay with the same owner.
User Impact
Users can tell that the file opened on the Gateway computer. Repeated actions receive fresh feedback; rejected opens retain the existing error guidance.
Evidence
46b7ee7c14ce7d12f6c935b9b584353fa6de177b: both real UI clicks opened the task config in a Gateway-side desktop window and returnedok: true, while the remote browser displayed no status.a81de763274990736b6cd31d70f073452618421b: both real UI clicks opened the file and displayed Configuration file opened on Gateway host. Runtime and UI came from one combined build per commit. This used a separate browser client, real Gateway requests, and the real Linux desktop opener.git diff --checkpass. Translation baseline generation leaves its bytes unchanged.Production: +4 lines for the missing outcome and translation; tests: +28 lines. No new setting, protocol, storage, dependency, or operation owner. The shared operation has no duplicate path to remove; failure alone needs clipboard work. Original contribution by @VasuBansal7576; report by @benmillerat. AI-assisted repair and verification.
Separate follow-up: inspect remote-browser success feedback for session workspace Reveal. It uses a different operation and has not been live-verified in this repair.