[codex] fix(gateway): open config on Windows by sweetcornna · Pull Request #90176 · openclaw/openclaw

sweetcornna · 2026-06-04T05:15:42Z

Summary

Replace the Windows dashboard config opener command from Start-Process -LiteralPath to Start-Process -FilePath.
Preserve the existing single-quoted PowerShell escaping so config paths stay data, not executable shell text.
Update the focused Gateway command-shape regression test.

Verification

node scripts/run-vitest.mjs src/gateway/server-methods/config.test.ts -t "uses Start-Process FilePath" --reporter=dot
node scripts/run-vitest.mjs src/gateway/server-methods/config.test.ts --reporter=dot
node scripts/run-vitest.mjs src/gateway/server-methods/config.test.ts ui/src/ui/controllers/config.test.ts --reporter=dot
npx oxfmt --check src/gateway/server-methods/config.ts src/gateway/server-methods/config.test.ts
node scripts/run-oxlint.mjs src/gateway/server-methods/config.ts src/gateway/server-methods/config.test.ts
git diff --check
node scripts/run-tsgo.mjs -p test/tsconfig/tsconfig.core.test.json

Real behavior proof

Behavior addressed: Dashboard Open config on Windows used the Gateway config.openFile method, which built a PowerShell command containing Start-Process -LiteralPath '<openclaw.json path>'. Start-Process supports -FilePath for files/documents, not -LiteralPath, so Windows users saw the dashboard request fail instead of opening openclaw.json.

Real environment tested: Local OpenClaw worktree at commit 3fcc6e50ab on macOS with dependencies installed via pnpm install --frozen-lockfile. The proof exercised the actual Gateway resolveConfigOpenCommand() implementation, the config.openFile Gateway test file, and the UI controller test that calls config.openFile. Microsoft Learn Start-Process docs for PowerShell 7.6 and 5.1 list [-FilePath] <string> as the file/program parameter.

Exact steps or command run after this patch:

node scripts/run-vitest.mjs src/gateway/server-methods/config.test.ts -t "uses Start-Process FilePath" --reporter=dot
node scripts/run-vitest.mjs src/gateway/server-methods/config.test.ts ui/src/ui/controllers/config.test.ts --reporter=dot
node --import tsx - <<'NODE'
import { resolveConfigOpenCommand } from "./src/gateway/server-methods/config.ts";
console.log(JSON.stringify(resolveConfigOpenCommand(String.raw`C:\tmp\o'hai & calc.json`, "win32"), null, 2));
NODE
node scripts/run-oxlint.mjs src/gateway/server-methods/config.ts src/gateway/server-methods/config.test.ts
npx oxfmt --check src/gateway/server-methods/config.ts src/gateway/server-methods/config.test.ts
git diff --check
node scripts/run-tsgo.mjs -p test/tsconfig/tsconfig.core.test.json

Evidence after fix:

RED before fix:
FAIL resolveConfigOpenCommand > uses Start-Process FilePath with a quoted PowerShell literal on Windows
Expected: "Start-Process -FilePath 'C:\\tmp\\o''hai & calc.json'"
Received: "Start-Process -LiteralPath 'C:\\tmp\\o''hai & calc.json'"

Focused Gateway + UI tests after fix:
Test Files  2 passed (2)
Tests  18 passed (18)
Test Files  1 passed (1)
Tests  43 passed (43)

Actual resolver output after fix:
{
  "command": "powershell.exe",
  "args": [
    "-NoProfile",
    "-NonInteractive",
    "-Command",
    "Start-Process -FilePath 'C:\\tmp\\o''hai & calc.json'"
  ]
}

Observed result after fix: The Windows opener now emits powershell.exe -NoProfile -NonInteractive -Command "Start-Process -FilePath '<escaped config path>'", preserving the existing quote escaping while using the supported Start-Process parameter.

What was not tested: I did not run a live Windows dashboard click-through or execute PowerShell locally because this macOS environment does not have pwsh, powershell, or powershell.exe installed. The changed command contract was validated against the actual Gateway command builder, existing UI config.openFile request tests, and Microsoft Learn parameter documentation.

clawsweeper · 2026-06-04T05:17:49Z

Codex review: needs maintainer review before merge. Reviewed June 4, 2026, 1:23 AM ET / 05:23 UTC.

Summary
The branch changes the Windows config.openFile command builder and matching regression test from Start-Process -LiteralPath to Start-Process -FilePath while preserving single-quoted path escaping.

PR surface: Source 0, Tests 0. Total 0 across 2 files.

Reproducibility: yes. for source reproduction: current main emits the exact invalid Windows PowerShell command, and pwsh rejects -LiteralPath while accepting -FilePath with -WhatIf. I did not run a full Windows dashboard click-through.

Review metrics: none identified.

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🐚 platinum hermit
Patch quality: 🦞 diamond lobster
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

Mark the draft ready for review when the contributor considers the branch final.

Risk before merge

[P1] No live Windows dashboard click-through was supplied; merge confidence rests on the actual resolver output, focused tests, official PowerShell docs, and a local pwsh parameter-binding check.

Maintainer options:

Decide the mitigation before merge
Land the narrow Gateway command fix after normal draft and merge gates, keeping the existing path escaping and the linked issue-closing relationship intact.
Pause or close
Do not merge this PR until maintainers decide whether the risk is worth taking.

Next step before merge

No ClawSweeper repair job is needed; the existing draft branch already applies the narrow fix and has no actionable review findings.

Security
Cleared: The diff only changes a PowerShell Start-Process parameter and the matching test, preserves existing path escaping, and does not touch dependencies, workflows, secrets, or package resolution.

Review details

Best possible solution:

Land the narrow Gateway command fix after normal draft and merge gates, keeping the existing path escaping and the linked issue-closing relationship intact.

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

Yes for source reproduction: current main emits the exact invalid Windows PowerShell command, and pwsh rejects -LiteralPath while accepting -FilePath with -WhatIf. I did not run a full Windows dashboard click-through.

Is this the best way to solve the issue?

Yes: changing the existing Windows branch in resolveConfigOpenCommand is the narrowest maintainable fix, and preserving the existing single-quote escaping keeps the path as data rather than shell text.

AGENTS.md: found and applied where relevant.

Codex review notes: model gpt-5.5, reasoning high; reviewed against ba445e0e3f32.

Label changes

Label changes:

add P2: The PR fixes a confirmed Windows dashboard Open config workflow bug with a narrow Gateway blast radius.
add proof: sufficient: Contributor real behavior proof is sufficient. The PR body includes after-fix live resolver output, red/green focused tests, and dependency documentation; it lacks a live Windows dashboard click-through but is sufficient for this command-shape fix.
add rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🐚 platinum hermit and patch quality is 🦞 diamond lobster.
add status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (live_output): The PR body includes after-fix live resolver output, red/green focused tests, and dependency documentation; it lacks a live Windows dashboard click-through but is sufficient for this command-shape fix.

Label justifications:

P2: The PR fixes a confirmed Windows dashboard Open config workflow bug with a narrow Gateway blast radius.
rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🐚 platinum hermit and patch quality is 🦞 diamond lobster.
status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (live_output): The PR body includes after-fix live resolver output, red/green focused tests, and dependency documentation; it lacks a live Windows dashboard click-through but is sufficient for this command-shape fix.
proof: sufficient: Contributor real behavior proof is sufficient. The PR body includes after-fix live resolver output, red/green focused tests, and dependency documentation; it lacks a live Windows dashboard click-through but is sufficient for this command-shape fix.

Evidence reviewed

PR surface:

Source 0, Tests 0. Total 0 across 2 files.

View PR surface stats

Area	Files	Added	Removed
Source	1	1	1
Tests	1	2	2
Docs	0	0	0
Config	0	0	0
Generated	0	0	0
Other	0	0	0
Total	2	3	3

What I checked:

Repository policy read: Read the full root policy plus scoped Gateway policy; the review-depth, dependency-contract, and Gateway server-method guidance were applicable. (AGENTS.md:1, ba445e0e3f32)
Current main still has failing Windows command: resolveConfigOpenCommand currently builds powershell.exe -Command Start-Process -LiteralPath ... for Windows, matching the reported failure mode. (src/gateway/server-methods/config.ts:184, ba445e0e3f32)
Current regression test locks the old behavior: The adjacent Windows command-shape test currently expects Start-Process -LiteralPath, so the PR correctly updates the focused expectation with the runtime change. (src/gateway/server-methods/config.test.ts:77, ba445e0e3f32)
UI caller path checked: The Control UI calls Gateway method config.openFile, so the Gateway command builder is the right owner boundary for this fix. (ui/src/ui/controllers/config.ts:523, ba445e0e3f32)
PR diff is scoped to the intended fix: The submitted diff changes only the Windows Start-Process parameter and the matching test expectation, leaving the existing quote escaping intact. (src/gateway/server-methods/config.ts:184, 3fcc6e50ab2b)
Latest release is still affected: Release v2026.6.1 at 2e08f0f4221f522b60423ed6ffd83427942b28de contains the same Start-Process -LiteralPath command, so this PR fixes a not-yet-shipped-on-main regression path rather than duplicating a released fix. (src/gateway/server-methods/config.ts:182, 2e08f0f4221f)

Likely related people:

mmaps: GitHub commit metadata for 5cc0bc936c4d6e2d9cf54ac81895a320e0cd0fbb identifies this account as the author of the config opener hardening that added resolveConfigOpenCommand and the Windows Start-Process -LiteralPath test path. (role: introduced behavior; confidence: high; commits: 5cc0bc936c4d; files: src/gateway/server-methods/config.ts, src/gateway/server-methods/config.test.ts)
vincentkoc: Recent GitHub path history shows several June 2026 Gateway config handler and config-open test refactors in the same files, including config facade bypass and shared config-open test helper work. (role: recent area contributor; confidence: medium; commits: deea78da72c5, 55467f0b9435, 51bad9b319c4; files: src/gateway/server-methods/config.ts, src/gateway/server-methods/config.test.ts)
Linux2010: Authored the merged Control UI/Gateway config-open failure feedback work that updated the same Gateway test and UI controller surfaces around failed config.openFile responses. (role: adjacent owner; confidence: medium; commits: 8246e91e9212; files: src/gateway/server-methods/config.test.ts, ui/src/ui/controllers/config.ts)

What the crustacean ranks mean

🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
🌊 off-meta tidepool: rating does not apply to this item.

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.

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.

sweetcornna · 2026-06-05T11:42:34Z

Closing this draft to reduce my active PR queue so newer ready fixes can be submitted under the repository's active-PR limit. The Windows config-open branch remains available on the fork if maintainers want to pick it back up.

fix(gateway): open config on Windows

3fcc6e5

openclaw-barnacle Bot added gateway Gateway runtime size: XS proof: supplied External PR includes structured after-fix real behavior proof. labels Jun 4, 2026

BradGroux mentioned this pull request Jun 4, 2026

WORKING: All Microsoft Issues and PRs (refresh) #74163

Draft

sweetcornna closed this Jun 5, 2026

This was referenced Jun 9, 2026

fix(config): use Start-Process -FilePath for Windows config opener #91536

Closed

Dashboard "Open config" fails on Windows: Start-Process -LiteralPath is invalid in all PowerShell versions #90157

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[codex] fix(gateway): open config on Windows#90176

[codex] fix(gateway): open config on Windows#90176
sweetcornna wants to merge 1 commit into
openclaw:mainfrom
sweetcornna:fix/90157-windows-open-config

sweetcornna commented Jun 4, 2026

Uh oh!

clawsweeper Bot commented Jun 4, 2026 •

edited

Loading

Uh oh!

sweetcornna commented Jun 5, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

sweetcornna commented Jun 4, 2026

Summary

Verification

Real behavior proof

Uh oh!

clawsweeper Bot commented Jun 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sweetcornna commented Jun 5, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

clawsweeper Bot commented Jun 4, 2026 •

edited

Loading