ce-work-beta Codex delegation: pre-checks pass, then Claude Code's auto-mode classifier blocks the codex exec launch (no fallback)

[giuseppebisemi]

ce-work-beta Codex delegation: pre-checks pass, then Claude Code's auto-mode classifier blocks the codex exec launch (no fallback)

Summary

Run ce-work-beta with delegate:codex and work_delegate_sandbox: yolo, and all four Pre-Delegation Checks pass. The workflow then tries to launch codex exec --dangerously-bypass-approvals-and-sandbox. In Claude Code's auto permission mode, the auto-mode classifier denies that command outright. The skill has no pre-check for this, no warning, and no documented fallback, so the run stops dead right after telling the user delegation is active.

The skill's Consent Flow gates on its own config file (work_delegate_consent: true in .compound-engineering/config.local.yaml). That is a separate authorization layer from Claude Code's Bash permission rules, and the two never meet. Writing consent into the skill config does not grant the harness permission to run the dangerous command.

Environment

• compound-engineering plugin 3.12.0, skill ce-work-beta
• Codex CLI codex-cli 0.139.0
• Orchestrator: Claude Code in auto permission mode
• No codex allowlist in settings.json or settings.local.json (default state)

Steps to reproduce

1. Write .compound-engineering/config.local.yaml with work_delegate: codex, work_delegate_consent: true, work_delegate_sandbox: yolo.
2. Run Claude Code in auto permission mode with no allowlist entry for codex exec.
3. Invoke the skill with delegate:codex on a plan file.
4. Watch the four Pre-Delegation Checks (platform gate, env guard, availability, consent) pass.
5. The skill reaches Execution Loop Step A and issues the background Bash call: codex exec -c model_reasoning_effort=high --dangerously-bypass-approvals-and-sandbox --output-schema ... -o ... - < prompt.

Expected

One of two behaviors:

• The skill confirms the launch will be permitted before it promises delegation. It checks the harness permission posture, or it folds a scoped codex exec allowlist rule into the consent flow.
• The skill catches the denial and falls back to standard mode, the same way it already handles other Pre-Delegation Check failures, and tells the user how to allowlist codex exec.

Actual

Claude Code's auto-mode classifier denies the launch. Its stated reason: the command spawns a Codex agent with --dangerously-bypass-approvals-and-sandbox, an unsafe autonomous agent loop the user never explicitly authorized. The four checks had already shown green, so the user is told delegation is active and then hits a wall with no recovery path the skill defines.

Root cause

references/codex-delegation-workflow.md treats the skill's config consent as enough authorization to run codex exec --dangerously-bypass-approvals-and-sandbox. The harness permission layer gates the actual launch, and the skill never inspects or reconciles it. Grep the whole skill and you find no mention of settings.json, Bash allowlists, the auto-mode classifier, or a harness-level denial of the launch command. The one permission note covers subagent mode, not codex exec. The skill marks yolo as Recommended, so the recommended path is the one most likely to be blocked.

Impact

In auto mode, Codex delegation does not work out of the box. The flag the skill recommends gets denied, nothing catches it, and the user is stranded mid-workflow. The failure stays hidden until the launch: every pre-check passes, so the user only finds out after the orchestrator has already written the scratch files, the prompt, and the schema. The defect lives in the shared references/codex-delegation-workflow.md, so it will reach stable ce-work too once delegation lands there.

Suggested fix (one or more)

1. Pre-check the harness permission posture before promising delegation. If codex exec is not allowlisted, guide the user to add a scoped Bash rule, or fall back to standard mode up front.
2. Fold harness allowlisting into the Consent Flow. When the user grants consent, offer to write a scoped allowlist rule such as Bash(codex exec:*) to settings.local.json.
3. Catch the launch denial and fall back gracefully, the way other Pre-Delegation Check failures already do.
4. Document that yolo-mode delegation needs the orchestrating harness to permit codex exec --dangerously-bypass-approvals-and-sandbox, so the Recommended label does not mislead users in auto mode.

Related issues

• ce-work-beta: delegation silently falls back to standard mode when references/codex-delegation-workflow.md is read relative to project CWD #949 (ce-work-beta: delegation silently falls back when codex-delegation-workflow.md is read relative to CWD). Same skill and same delegation flow, different failure mode. There the workflow file never loads; here it loads, the pre-checks pass, and the launch itself is denied. This bug sits downstream of ce-work-beta: delegation silently falls back to standard mode when references/codex-delegation-workflow.md is read relative to project CWD #949.
• ce-compound: pre-resolved repo-name command (git ... | sed ...) blocked by Claude Code multi-operation permission check #795 and ce-sessions: pre-resolved repo-name uses $(…) command substitution, blocked by Claude Code permission check (sibling of #795) #816 (Claude Code permission layer blocks a pre-resolved skill command). Same family of "the harness blocks what the skill assumes it can run," but those trip the static-analysis and multi-operation checks on inline bash, while this one trips the auto-mode danger classifier on the codex exec launch.

Notes

A workaround today: add a Bash rule allowing codex exec to settings.local.json, or run delegation in a permission mode that prompts interactively instead of auto-denying. The skill mentions neither.

[m13v]

the thing that bites here isn't the consent flag, it's that you've got two authorization layers that never reconcile: the skill's config consent and the harness permission classifier. that pattern shows up any time you shell one agent out through another agent's bash, codex exec inherits Claude Code's permission posture instead of carrying its own. green pre-checks then a wall at launch is the signature. driving each backend over ACP directly sidesteps it, since the host gates per backend instead of nesting one agent's launch inside the other's danger classifier.

[tmchow]

we are retiring ce-work-beta in #1013