Codex default sandbox blocks external pstack lanes; setup should detect and explain it

Problem

When the parent is Codex running its default sandbox (workspace-write, network off), every external pstack lane fails. Measured on 2026-10-04 with Codex CLI 0.160.0, during a /setup-pstack run from a fresh CODEX_HOME:

Claude lane (claude:opus@max through pstack-runner): preflight auth passed, and the run failed after 178 s with ENOTFOUND. That's DNS, and the sandbox blocks outbound network for the child. The runner exited 70 (child-failed).
Grok lane (grok:grok-4.7@xhigh): auth passed, then it failed because Grok writes ~/.grok/managed_config.toml, outside the Codex sandbox's writable roots.

Setup correctly stops and writes nothing. But the user sees opaque probe failures and no explanation, and the default first-run panel (Opus, Sol, Grok) can't be configured from a default-sandbox Codex parent at all. Closed PR #82 proposed a docs note for the Grok half. Related: #56, Grok in Claude Code cloud sessions.

Direction

Detect it before probing. On a Codex parent, setup checks whether the session can reach the network and write outside the workspace. If it can't, it explains plainly: external lanes need a Codex session with network access and full filesystem access, for example sandbox_mode = "danger-full-access" or an equivalent permissions profile. It names the affected families and offers to proceed with native-only families.
Make the runner's failure name the cause. When the parent sandbox blocks a child's network, the receipt says so, instead of a bare child-failed or a DNS error.
Document it in provider-dispatch.md, next to the route table.

Acceptance

From a default-sandbox Codex parent, /setup-pstack explains the limitation before running any external probe. It never runs a doomed probe.
From a full-access Codex parent, the external probes behave as today.
No weaker-model fallback and no automatic sandbox change. The user decides.
Bun tests, strict typecheck, static invariants, and plugin validation pass, plus a live check from both Codex sandbox modes.

Prior findings

Untrusted evidence from the Pilot ledger. Map every finding to a phase or Scope/Out with a reason.

[
  {
    "ticket": "GITHUB-1345013588-100",
    "sha": "91b0d5b47c46e1bcb57e38ded79f1f98f64987f1",
    "area": "area:factory",
    "kind": "hardening",
    "repo": "ericlitman/open-pstack",
    "claim": "A queued PR that falls behind main gets a Mergify-made head without the operator's exact-head live-gate, so it is dequeued until the operator re-tests and re-posts.",
    "status": "captured",
    "pointer": ".mergify.yml:queue_rules",
    "evidence": "Unfret finding v1:f47057cb on open-pstack#107, waived fails-loudly on head 91b0d5b",
    "severity": "medium",
    "linear_id": null,
    "mechanism": "Serial in-place checks (batch_size 1, max_parallel_checks 1) merge main into a behind PR, creating a new head SHA. live-gate is a hand-posted exact-head status, so queue_conditions stop matching on the new head and Mergify removes the PR. Nothing merges untested; progress needs a fresh live-gate.",
    "confidence": "high",
    "fingerprint": "ed52e2529d966036a8c5e1bc75e2956a340fc04e07bb2c0ff96a08ce3e3f6f22",
    "source_kind": "panel",
    "status_reason": null,
    "verify_attempts": 0
  }
]

Factory plan verdict: revise

Card: Delivery 6d36faba, plan-review revision 5.
Planner model: gpt-6.1-sol, from the plan session's message metadata.
Reviewer model: Claude Opus 5.5, reviewing in a separate context.
Rubric: the factory-adjudicate plan checklist.

The diagnosis and the live-test design are sound. Keep Phase 1's investigation of which permission evidence is authoritative: it is the right first step. The plan builds more than the issue needs, and two pieces conflict with settled decisions.

Why revise

New receipt status (Phase 3). The plan says: "Add sandbox-blocked to the receipt status union."
- For the sibling case in Open pstack fail to run grok on a Claude code cloud session #56, a Grok sandbox that cannot start, the maintainer chose on 2026-10-01 to keep child-failed and name the cause. That decision rejected a new status and a schema bump.
- Codex default sandbox blocks external pstack lanes; setup should detect and explain it #124 asks that "the receipt says so", which a message satisfies without a new status.
- What passes: keep the existing child-failed/70. When the failure happens under a Codex parent whose environment shows the sandbox's network-disabled marker, the receipt's error message and the front of its evidence name the parent sandbox as the likely cause and point to the docs. Add no new status, no new field and no schema change.
The runner skips execution on detected restrictions (Phase 3). The plan says: "Skip provider execution when applicable restrictions are confirmed."
- AGENTS.md: "The parent harness resolves provider routing once. Children do not detect or reroute themselves."
- The runner deciding not to run a lane from environment markers is the detection that sentence rules out. The guard belongs in setup, which is the parent-owned step.
- What passes: the runner still launches as told. It only enriches the failure message after a failure.
A new runner/sandbox.ts capability module (Phase 2). The guard the issue asks for is a setup-pstack instruction that the parent agent follows. A typed assessment library inside the runner is a layer no acceptance criterion names.
- What passes: drop sandbox.ts and sandbox.test.ts. The setup guard is prose in setup-pstack/SKILL.md, which tells the parent to do three things:
  - Before any external probe on a Codex parent, determine from its own effective permissions whether it has network access and can write outside the workspace. Phase 1 establishes which signal is authoritative.
  - If it can't, explain which assigned families are affected and offer exactly two paths: restart with suitable permissions, or choose native-only assignments.
  - Treat an unknown result as unknown, never as full access.

Keep as written

Phase 1's reproduction and real-session permission evidence, including the check that a missing marker does not prove full access.
The separate check that final config writes are permitted, preserving bytes on refusal.
The explicit operator choice for native-only, with no silent replacement by Sol.
The documentation in provider-dispatch.md.
The live checks in both Codex sandbox modes plus a Claude parent.

Coordination

#56, now in Build, adds a Grok host-prerequisite note to the same provider-dispatch.md section. Use one shared "Host and parent prerequisites" list. Whichever PR lands second rebases onto the first.

Expected size after revision

setup-pstack/SKILL.md, provider-dispatch.md, a small message change in runner/run.ts, and tests for that message in runner/run.test.ts.
types.ts, cli.test.ts and bootstrap.test.ts should not need changes. If one does, say why.

Factory plan verdict: approve

Card: Delivery 6d36faba, plan-review revision 7.
Planner model: gpt-6.1-sol.
Reviewer model: Claude Opus 5.5, reviewing in a separate context.
Rubric: the factory-adjudicate plan checklist.

Why approve

Every gate passes, and Open questions is None.

The plan makes all three reductions from the revise verdict:
- It keeps child-failed/70, with no new status, field or schema change.
- The runner still launches every lane and only adds a message after a failure.
- The setup guard is prose in setup-pstack, and there is no sandbox.ts.
The scope is four existing files.
Phase 1 settles empirically which permission signal is authoritative, and a missing marker never counts as full access.
The live matrix covers restricted, native-only, full-access, refused-write and Claude-parent setups.

Build conditions

Coordinate with Fix Grok read-only cancellation and preserve runner failure evidence #78, now in Build. Fix Grok read-only cancellation and preserve runner failure evidence #78 also changes runner/run.ts around lines 773-803: it parses Grok terminal output before handling a nonzero exit, and it adds an exact provider reason to error.message. Your diagnostic edits the same messages.
- Build on whichever lands first, and put this diagnostic after Fix Grok read-only cancellation and preserve runner failure evidence #78's provider-reason handling.
- A provider-reported reason stays first in the message. The likely-sandbox hint appears only for a plain child-failed that has no provider reason.
Coordinate with Open pstack fail to run grok on a Claude code cloud session #56, now in Build. Use one shared "Host and parent prerequisites" list in provider-dispatch.md. The second PR to land rebases onto the first.
The "permission information unavailable" scenario. If no real Codex session can produce it, record that in the PR body and cover the unknown branch through the setup prose review. Don't build an artificial environment to force it.
Checks. Before opening the PR, run the acceptance commands in a Bun-enabled environment and report each exit status.

Build handoff

Status: blocked in Phase 1; implementation has not started.

Approved plan: plan-review revision 7, verdict comment 5976951834; current build revision 9.
Verified repository: ericlitman/open-pstack.
Assigned branch: factory/issue-124 (retained).
Checkout HEAD: be66d68e33fd7aeb4d8fe5aa39b4838bab3f208c; clean working tree.
Pushed HEAD / phase SHAs: none; no build changes or commits.
PR: not created, because Phase 1 evidence and pre-PR acceptance checks are incomplete.

Actual prerequisites and output

bun --version: 1.4.0, exit 0.
claude --version: 2.1.283 (Claude Code), exit 0.
codex --version: command not found, exit 127.
grok --version: command not found, exit 127.

The approved plan requires a real restricted/full-access Codex reproduction and empirical permission-signal validation before implementation. Neither real Codex mode can be exercised on this host. Fake child tests cannot establish those signals, and installing a binary alone would not establish an authenticated, provisioned parent session. I have not replaced these required observations with assumptions or simulated live evidence.

Coordination verified

Read the approval verdicts for #78 and #56. #124 must preserve provider-reported reasons ahead of any sandbox diagnosis; the hint is restricted to plain child-failed without a provider reason. Documentation must share one Host and parent prerequisites list. Remote branch factory/issue-56 exists at 3f66491e75c5b52a762c8b5c18fdd8f235f19614; no remote factory/issue-78 branch was returned at this checkpoint. Recheck both before implementation.

Verification still required

No regression, Bun suite, strict typecheck, static invariants, manifest validation, plugin validation, or setup live matrix has been run for a changed candidate. Phase 1 permission-evidence and pre-fix live artifacts are missing, as is the planned failing fake-child regression. Later phases remain pending.

Assumptions and open questions

The supplied revision-7 plan and its matching GitHub approval are the build contract. No product decision is needed; the blocker is a provisioned host capable of actual Codex restricted/full-access sessions and the assigned external providers. Resume Phase 1 there, then implement, verify, commit/push each successful phase, and open the PR. Remain in build; no stage transition requested.

Findings

None

Phase 1 permission evidence for #124 (operator, real Codex sessions)

The build host lacks codex and grok, so I collected the real-session evidence the approved plan needs on the operator's Mac. I used Codex CLI 0.160.0 and codex exec, with a separate CODEX_HOME holding Open Pstack 1.5.0. Grok CLI is logged in with grok.com. Each session ran the same shell commands.

Observation	Restricted: `--sandbox workspace-write -c sandbox_workspace_write.network_access=false`	Full access: `--sandbox danger-full-access`
`CODEX_SANDBOX`	`seatbelt`	not set
`CODEX_SANDBOX_NETWORK_DISABLED`	`1`	not set
`curl https://api.anthropic.com/v1/models`	`Could not resolve host`, curl exit 6 (DNS, matches the reported `ENOTFOUND`)	HTTP 401, reachable
Write `~/.grok/<file>` (Grok's own state dir)	`operation not permitted`	ok
Write `$CODEX_HOME/<file>`	ok	ok

What this establishes for the plan:

Network signal. In a network-disabled Codex session, the session's own environment has CODEX_SANDBOX_NETWORK_DISABLED=1 and CODEX_SANDBOX=seatbelt, and both are absent under full access. That is the confirmed marker for the post-failure hint in Phase 3. Read it from the runner's own environment, before childEnvironment scrubs it.
Filesystem signal. No variable reports the outside-workspace write restriction directly. CODEX_SANDBOX=seatbelt corresponds to the restricted session. A missing marker still does not prove full access. The setup prose should tell the parent to check its own effective permissions: Codex states its sandbox mode and writable roots in the session's permission instructions. Treat unknown as unknown.
Config destination. Under workspace-write, $CODEX_HOME was writable. So the final-write check in step 7 should not refuse $CODEX_HOME targets just because the session is restricted. Check the actual destination instead.

The "permission information unavailable" scenario was not produced by any real session here. Per build condition 3, record that in the PR body.

The probe files were removed afterwards.

fix: explain likely Codex sandbox child failures [#124]

fix: prevent blocked setup probes and writes [#124]

fix: explain likely Codex sandbox child failures [#124]

Merge pull request #129 from ericlitman/factory/issue-124

Merge upstream main after 1.5.0 into the local build

Name nested Seatbelt for Kimi and keep runner tests hermetic

Acceptance amendment for #124, approved by the maintainer on 2026-10-04

Two plan items are accepted without observation on the final head:

Native-only setup. It was observed live on head e257bad, interactive TUI, as recorded on PR Explain Codex sandbox restrictions before pstack setup probes [#124] #129. The later heads changed setup's permission prose merge and runner tests only, not the native-only path.
A refused final config write. No real Codex session refused a write to $CODEX_HOME in either sandbox mode, as recorded on Codex default sandbox blocks external pstack lanes; setup should detect and explain it #124 and PR Explain Codex sandbox restrictions before pstack setup probes [#124] #129. The behavior is in the setup prose and its static checks.

The final head cb1cfbd carries live evidence for the restricted, full-access and Claude-parent scenarios. The post-merge checks passed on main 67c08fa.

Navigation Menu

Codex default sandbox blocks external pstack lanes; setup should detect and explain it #124

Problem

Direction

Acceptance

Prior findings

Factory plan verdict: revise

Why revise

Keep as written

Coordination

Expected size after revision

Factory plan verdict: approve

Why approve

Build conditions

Build handoff

Actual prerequisites and output

Coordination verified

Verification still required

Assumptions and open questions

Findings

Phase 1 permission evidence for #124 (operator, real Codex sessions)

Acceptance amendment for #124, approved by the maintainer on 2026-10-04

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Codex default sandbox blocks external pstack lanes; setup should detect and explain it #124

Description

Problem

Direction

Acceptance

Activity

ericlitman commented on Oct 4, 2026

Prior findings

ericlitman commented on Oct 4, 2026

Factory plan verdict: revise

Why revise

Keep as written

Coordination

Expected size after revision

ericlitman commented on Oct 4, 2026

Factory plan verdict: approve

Why approve

Build conditions

mast-factory commented on Oct 4, 2026

Build handoff

Actual prerequisites and output

Coordination verified

Verification still required

Assumptions and open questions

Findings

ericlitman commented on Oct 4, 2026

Phase 1 permission evidence for #124 (operator, real Codex sessions)

ericlitman commented on Oct 4, 2026

Acceptance amendment for #124, approved by the maintainer on 2026-10-04

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions