[AmeinEskinder]

Why

Claude writer lanes fail before launch on Windows because Bun refuses inline JSON arguments to claude.cmd. Pass the sandbox settings as a file path while preserving every sandbox control and the shared Git directory write denial. Fixes #230.

What changed

• Write Claude settings into the existing private provider sidecar after shared Git discovery.
• Pass that file to --settings and retain the current permission and tool controls.
• Exercise a real Windows command file and update the runner verifier to check and retain the settings file.

Scope

• Covers launcher settings transport and its associated verification.
• Bounded writers still require a working provider sandbox. This change does not enable the Windows sandbox feature gate.

Tradeoffs

Provider sidecars are declared per adapter, so Claude readers also reserve an empty settings file. Readers continue to request plan mode without passing --settings.

Blast Radius

Provider config builders can receive the discovered shared Git directory. Existing providers keep their current config contents, and exclusive file creation still fails closed.

Verification

• Windows regression fails before the fix with Bun's args[9] error. The regression and Claude adapter tests pass after the fix, 22 tests total.
• Linux Bun suite passes 503 tests. Strict typecheck and static invariants pass, including 167 verifier tests. Claude plugin validation passes.
• A real Windows Claude launch consumes the settings file and refuses startup because this session's Windows sandbox feature gate is off. No installed-harness live gate was published. The pending native verifier features are claude:runner, codex:runner, and both project-skill cases.

[mergify]

Merge Protections

🟠 1 of 2 protections blocking · waiting on 🤖 CI

	Protection	Waiting on
🟠	Queue ready pull requests	🤖 CI
🟢	🚦 Auto-queue	—

🟠 Queue ready pull requests

Waiting for

• check-success=Unfret
• check-success=live-gate
• check-success=verify

Waiting checks: Unfret, live-gate, verify.

Automatically queue non-draft pull requests targeting main after verify, Unfret, and live-gate pass on the head and every review thread is resolved.

• check-success=Unfret
• check-success=live-gate
• check-success=verify
• #review-threads-unresolved = 0
• -draft

---

Show 1 satisfied protection

🟢 🚦 Auto-queue

When all merge protections are satisfied and these conditions match, this pull request will be queued automatically.

• -files~=^\.github/
• base = main

[greptile-apps]

[Medium impact] The code changes appear safe to merge, subject to the repository’s required exact-head live gate.

Summary

Moves Claude writer sandbox settings from inline JSON to a private settings.json file.

• Claude writer runs load sandbox rules from a sidecar file.

No actionable defects were found. This review used source inspection; tests and live launches were not run.

_{Reviews (1) · Last reviewed commit: "fix(runner): load Claude sandbox setting..." · Reviewed by Greptile}

[ericlitman]

Thank you for this, and for the clear diagnosis. Tracing the failure to args[9] and keeping the Windows sandbox separate from argument transport made it easy to review. On macOS at 7e89581, the Bun suite, typecheck, static checks and plugin validation all pass.

We aren't merging it now. Claude Code's sandboxing docs say the sandbox runs on macOS, Linux and WSL2, and that on native Windows Claude Code runs commands unsandboxed. The runner sets failIfUnavailable for Claude writers on purpose. So after this change a Windows writer lane still can't start, and only the error changes. The quoting failure also needs the npm claude.cmd shim: claude.exe from the native installer or WinGet doesn't go through cmd. Under WSL2, Claude writer lanes work today.

#230 stays open until Claude Code supports the sandbox on native Windows. Your settings-file design is the one we'd port then, with you as co-author. Could you post the Claude Code version and the startup message that mentioned the Windows sandbox feature gate? If Claude Code gives you a way to turn that sandbox on, tell us on #230 and we'll pick this up again.