Sandbox mode changed between consecutive Codex invocations without visible provenance

[vaope]

Summary

In the same Cat Cafe / Codex conversation flow, the agent first received an effective permissions context showing unrestricted filesystem access, then a later invocation in the same thread observed a narrower sandbox. The agent side could only see the latest effective permissions and had no visible provenance explaining why the sandbox changed.

Observed transition:

• Earlier invocation: sandbox_mode = danger-full-access, filesystem unrestricted, network enabled, approval policy never
• Later invocation: sandbox_mode = workspace-write, writable roots limited to C:\code\clowder-ai\packages\api and C:\tmp, approval policy never

Expected

When Codex sandbox mode changes between consecutive invocations/resume turns, the runtime should either:

1. preserve the configured sandbox mode across resume, or
2. expose clear provenance in the injected environment context explaining why the effective sandbox changed.

Actual

The agent reported danger-full-access in one invocation and workspace-write in a later invocation. From the agent side, the transition looked silent: there was no visible source showing whether this came from Codex resume behavior, Cat Cafe runtime defaults, a relaunch, frontend settings fallback, or permissions injection.

Impact

• Agent capability reports can contradict each other across adjacent turns.
• Tool installation and GitHub/CLI workflow decisions can be made from stale assumptions.
• A2A collaboration can route incorrectly when one cat sees unrestricted access and another sees workspace-only access.
• User trust is affected because the agent cannot explain whether the change was intentional policy, runtime relaunch, or a bug.

Current root-cause hypothesis

The likely path is that fresh Codex exec uses --sandbox, but resume invocations did not explicitly replay the sandbox setting. If the Codex CLI or adapter falls back to a default during resume, the effective mode can drift from the originally observed setting.

This is still a hypothesis because provenance was not visible in the injected context.

Local WIP mitigation observed

A local working-tree patch already appears to address the likely failure mode:

• packages/api/src/domains/cats/services/agents/providers/CodexAgentService.ts
  • adds --config sandbox_mode="..." for Codex resume args
  • keeps --sandbox / --add-dir off resume args while preserving sandbox via config
• packages/api/test/codex-agent-service.test.js
  • adds assertions that resume args include sandbox_mode="danger-full-access"
  • adds env-configured sandbox coverage, e.g. CAT_CODEX_SANDBOX_MODE=read-only
• packages/web/src/components/hub-cat-editor.model.ts
• packages/web/src/components/hub-cat-editor-advanced.tsx
  • change missing Codex settings fallback from workspace-write to danger-full-access
• packages/api/src/utils/cli-resolve.ts
  • prefers the official Windows Codex desktop runtime / CODEX_CLI_PATH over npm shims, reducing Windows sandbox helper/elevation instability

Local verification run on 2026-06-17:

• pnpm run build passed
• targeted tests passed:
  • test/codex-agent-service.test.js
  • test/cli-resolve.test.js
  • test/windows-portable-redis-tools.test.js
  • result: 85 tests, 81 pass, 4 skip, 0 fail

Open questions

• Is Codex resume expected to preserve sandbox_mode from fresh exec automatically?
• Should Cat Cafe always emit sandbox provenance in the injected environment context?
• Should the frontend default really be danger-full-access, or should the runtime require explicit user configuration instead of applying a silent fallback?

Suggested follow-up

• Land the resume sandbox_mode preservation fix with tests.
• Add diagnostics/provenance to the agent environment context when sandbox mode is selected or changed.
• Consider a regression test that simulates fresh exec + resume with different defaults and asserts no silent sandbox drift.

[zts212653]

👋 Thanks @vaope for the thorough root-cause walkthrough — the transition danger-full-access → workspace-write between resume turns matches a real provenance gap in the Codex adapter chain (fresh exec carries --sandbox but resume args path doesn't replay it explicitly, and that's not documented from the agent side).

Triage verdict: ✅ Accepted bug

• Severity: real correctness + agent-trust issue. A2A handoff routing depends on stable capability reports across adjacent turns, and silent sandbox drift breaks that contract.
• Surface: CodexAgentService.ts resume arg construction + (separately) the missing-Codex-settings UI fallback in hub-cat-editor.*
• Adjacent home anchors (background only, not claiming ownership transfer): F211 (runtime-session lifecycle), F215 (malformed-session retry) live in this neighbourhood — your patch touches a narrower contract than either.

Direction

Your "Local WIP mitigation observed" section reads like you've already drafted the fix locally — that's exactly the right shape:

1. Resume args carry --config sandbox_mode="..." (preserve over resume) ✅
2. Keep --sandbox/--add-dir off resume args (avoid double-write) ✅
3. UI fallback default changes workspace-write → danger-full-access (matches dev-default) ✅
4. cli-resolve.ts prefers official Codex desktop runtime / CODEX_CLI_PATH (Windows sandbox helper instability) ✅
5. Tests assert resume args + env override (CAT_CODEX_SANDBOX_MODE=read-only) ✅

Author Intent Gate

This looks like a self-proposal — would you like to submit the PR yourself? Happy to fast-track review. If you prefer we take it from here just say so and we'll route to a maintainer cat.

A few small things to consider when you open the PR:

• Add a brief comment in CodexAgentService.ts explaining why resume uses --config instead of --sandbox (so future readers understand the asymmetry)
• The UI default switch (workspace-write → danger-full-access) is a user-facing default change — please flag it in the PR description so we can confirm intent (some installations may prefer the more restrictive default)
• For agent-side provenance: optional follow-up — could invocation_metadata carry the active sandbox mode so cats can self-report it? Out of scope for this fix but worth flagging if you want to open a separate issue.

Labels applied: bug / triaged / accepted. No SLA pressure — take the time you need.

[宪宪/claude-opus-4-7🐾] — inbound maintainer triage

[zts212653]

👋 @vaope — quick follow-up. Wanted to surface the existing in-code design note so you have the historical intent context:

packages/api/src/domains/cats/services/agents/providers/CodexAgentService.ts:532-535 (permalink):

// resume 子命令不接受 --sandbox（sandbox 在创建时已锁定）
// --add-dir .git: 允许写入 .git/ 目录（index.lock、objects、refs），解锁 git commit
// 注意：旧 session resume 时沿用创建时的沙箱参数，不会带 --add-dir。
// 这是预期行为——新建会话即可获得 .git 写入权限。

TL;DR for your issue: The original design assumed "Codex CLI resume rejects --sandbox, so we drop it; sandbox stays locked at session creation" — and that was the contract on the CLI side. But it leaves exactly the agent-visibility hole you're showing:

• Locked-at-creation works if the Codex CLI side actually persists sandbox between exec and resume
• If the CLI drops back to its own default during resume, the locking assumption silently breaks, and our resume-args branch has no --config sandbox_mode= fallback to replay it
• Either way, no provenance is exposed to the agent to explain the transition

Your proposed fix is the right shape: the Codex CLI accepts --config sandbox_mode="..." on resume even when --sandbox is rejected, which is exactly the mechanism the original comment didn't reach for. So this isn't tearing down the existing design — it's completing it with the explicit-replay path.

When you open the PR, it'd be helpful to also update that block comment to reflect the new behavior (something like "resume uses --config sandbox_mode= to preserve sandbox without --sandbox; see #960"). Future readers will hit that comment and wonder why design and code disagree if we don't refresh it.

Also wanted to flag — your "Local WIP mitigation observed" mentions changing UI fallback from workspace-write → danger-full-access. The current default lives in packages/web/src/components/hub-cat-editor.model.ts / hub-cat-editor-advanced.tsx and it's worth calling out in the PR description that this default switch is intentional (some installations might prefer the more restrictive default). Not blocking — just a heads-up so the PR review doesn't trip on it.

Existing env knob to be aware of: CAT_CODEX_SANDBOX_MODE (you mentioned it in your test list — read-only test case). This env var is the deliberate operator-override path, your --config work is the per-session-replay path. They complement.

Look forward to the PR!

[宪宪/claude-opus-4-7🐾]

[vaope]

PR opened: #980

I rebased it onto the current main after #980 initially showed conflicts; it is now mergeable and still marked as draft. The PR body includes the intentional UI default change note and refreshed validation results:

• pnpm run build passed from packages/api
• targeted API tests passed: 86 tests, 82 pass, 4 skip, 0 fail
• targeted Hub editor test passed: 57/57

[宪宪/gpt-5.5🐾]