docs(dispatch): note that Grok lanes need an unsandboxed Codex parent

[smashru]

What changed

provider-dispatch.md already says the parent's tool sandbox controls whether a child CLI can reach its credentials and network. This adds the Grok-specific case, which fails in two ways that don't look like a sandbox problem from the receipt alone. On macOS, a Codex parent running any sandbox cannot host a Grok lane:

• read-only, or workspace-write without network. grok models cannot reach the API and falls back to its built-in model list. The preflight then records unavailable-model for a current model such as grok-4.7, which reads like an account or model problem.
• workspace-write with network. Grok exits with "could not apply the 'workspace' sandbox profile ... Refusing to start with its protections missing", because macOS sandboxes do not nest. The receipt records child-failed.

The note says a Codex parent that routes roles to grok:* must run with danger-full-access, chosen deliberately in the user's profile. Grok's own sandbox still confines the lane. The note keeps the existing rule that a blocked CLI is a dropout, never a reason for the parent to escalate itself.

Docs only. No runner or skill behavior changes. Found while verifying #81.

Verification

• Bun tests, strict typecheck, static invariants, and plugin validation pass. Static invariants and git diff --check pass. No code or manifest changed.
• The exact candidate is installed in every affected harness. Not applicable to a docs-only change. The behavior it describes was observed with Open Pstack 1.4.1 plus fix(runner): let headless Grok writers run shell commands #81 installed in Codex.
• The changed behavior passes from each real user surface.
• The installed version, action, and observed result appear below.

Live evidence (macOS, codex-cli 0.155.1, grok CLI 1.0.34, grok:grok-4.7@xhigh isolated-write lane launched by a codex exec session through the installed pstack-runner):

Codex sandbox	Receipt	Grok evidence
workspace-write, no network	exit 69, unavailable-model	preflight listed only grok-4.6, grok-4.5, plus "HTTP export failed: network error"
workspace-write, network on, ~/.grok writable	exit 70, child-failed	"sandbox initialization failed: Operation not permitted", "could not apply the 'workspace' sandbox profile"
danger-full-access	exit 0, complete, grok-4.7-build verified	lane output GIT_STATUS: ## HEAD (no branch)

🤖 Generated with Claude Code

[mergify]

This pull request does not currently match the merge queue conditions, so it cannot be queued from here. The box comes back if it matches again.

[greptile-apps]

Confidence Score: 5/5

The documentation-only change appears safe to merge.

Summary

Documents the macOS sandbox constraints for Grok lanes launched by a Codex parent.

• Explains the distinct unavailable-model and child-failed outcomes produced by restricted parent profiles.
• Requires users to deliberately start the Codex parent with danger-full-access while retaining Grok's child sandbox.
• Preserves the rule that blocked provider CLIs remain dropouts rather than triggering automatic privilege escalation.

_{Reviews (1) · Last reviewed commit: "docs(dispatch): note that Grok lanes nee..."}

[openswebot]

✅ Open SWE Review: No issues found

Open SWE reviewed this PR and found no potential bugs to report.

Open in Web

[ericlitman]

Thanks for this, @smashru. I appreciate the time you put into it. Open Pstack now accepts contributions as detailed issues rather than pull requests, so I'm closing this one. If it's still relevant, please open an issue describing the problem, how to reproduce it, and the change you'd suggest. I'll take it from there.

[ericlitman]

Follow-up to the close: this work is already tracked in #56, so there is no need to open a new issue. This PR is noted there as prior art and will be credited when the fix lands.