codex worker `-c` overrides never reach the npm codex-acp adapter (sandbox, approval policy, reasoning effort silently dropped)

[Quigleybits]

What

_augment_acp_command configures codex workers by appending -c overrides to the ACP command line (src/zenith_harness/acp_runner.py:109-116):

codex-acp -c sandbox_mode="danger-full-access" -c approval_policy="never" -c model_reasoning_effort="xhigh"

The worker adapter the README documents (npm install -g @agentclientprotocol/codex-acp, matching providers.py's default_worker_acp_command="codex-acp") does not parse these. Its entrypoint (verified against @agentclientprotocol/codex-acp 1.1.0 dist/index.js) inspects argv only for --version and the login / cli subcommands; a bare invocation starts the ACP server configured solely from env: CODEX_CONFIG (JSON), CODEX_PATH, MODEL_PROVIDER, DEFAULT_AUTH_REQUEST. All three -c overrides are silently discarded.

Impact

• model_reasoning_effort — hardcoded xhigh today, per-role once feat(config): make codex reasoning effort configurable per role #17 lands — never reaches the worker. The adapter resolves effort from the model default instead, and clamps unsupported values to the model default (findSupportedEffort), so the misconfiguration is silent.
• sandbox_mode / approval_policy intent rides only the env-var hints already present in _acp_subprocess_env (CODEX_SANDBOX, CODEX_DISABLE_SANDBOX, commented "harmless if codex ignores them") — not the adapter's actual configuration contract.
• Existing tests assert the constructed command string, so the delivery failure is invisible to CI.

Proposed fix

Build CODEX_CONFIG JSON in _acp_subprocess_env for codex workers (merging any user-supplied CODEX_CONFIG), carrying sandbox mode, approval policy, and reasoning effort; wire the per-role effort values from #17 once it lands. Happy to send that PR.

One question first

If a different codex-acp build (e.g. a -c-honoring binary) is the canonical adapter in your setups, the fix should target whichever contract you consider supported — please confirm which adapter Zenith targets.

Found while amending #17; verified locally against the npm adapter 1.1.0 (Windows install, global npm).

🤖 Generated with Claude Code

[stephanbrez]

Another suggestion here, if you're going to be plumbing those in, also add support for specifying model names e.g. '-c model="gpt-5.6-luna"',

[ofekron]

The key invariant here is that the worker's effective runtime config must be observable after spawn.

For sandbox mode, approval policy, and reasoning effort, I would verify against the adapter's actual supported configuration path, not only wrapper argv. If ACP drops those fields, the harness should surface that as config drift before the worker starts doing real work.

I maintain Better Agent (https://github.com/ofekron/better-agent), and this exact drift class is risky: the UI/config can claim one safety profile while the live agent is running under another.

If Better Agent is useful as a reference for provider runtime config checks, a star helps others find it.