[Bug]: Codex child started by delegate_task on macOS gets a dead shell (every command exits 134) when the user's config sets default_permissions to a custom [permissions] profile; the built-in :workspace default works

[kamil-koryciorz]

Before submitting

• I searched existing issues and did not find a duplicate. (Searched "codex exit 134", "delegate_task codex sandbox", "codex child shell", "default_permissions". Related, not duplicates: discussion [Feature]: Allow Codex sessions to inherit configured permission profiles #6976 asks for an option to inherit the user's Codex permission profile instead of T3's own sandbox settings; issue ProviderAdapterProcessError: codex #4292 (closed) is a startup refusal when T3's sandbox/approval combination conflicts with a managed policy; [Feature]: An unattended read-only mode for delegate_task Codex children (approvalPolicy: never + sandboxPolicy: readOnly) #15381 asks for a read-only mode for Codex children. None of them reports a child whose shell aborts.)
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Codex CLI 0.160.1, authenticated. In ~/.codex/config.toml define a custom permissions profile and make it the default:

default_permissions = "claude-only"

[permissions.claude-only]
description = "Projects only; one folder explicitly denied."

[permissions.claude-only.filesystem]
":root" = "deny"
":minimal" = "read"
"~/Projects" = "write"
"~/.t3/scratch" = "write"
"~/.t3/worktrees" = "write"
"~/<denied-folder>" = "deny"
"~/.config/gh" = "read"
"~/.gitconfig" = "read"
"~/.codex/packages" = "read"
"~/.local/bin" = "read"

[permissions.claude-only.network]
enabled = true

[permissions.claude-only.network.domains]
"api.github.com" = "allow"
"github.com" = "allow"

2. From a Claude thread (orchestrator V2), call delegate_task with target.providerInstanceId = "codex", model = "gpt-6-sol", runtimeMode = "auto", mode = "wait", task text: run echo probe-ok and report the raw tool result.
3. Change only line 1 to default_permissions = ":workspace" and repeat step 2.

Expected behavior

Both runs execute the command inside the child's sandbox and return probe-ok.

Actual behavior

• With the custom profile as default: every exec_command returns at once with {"exit_code":134,"wall_time_seconds":0.000006,"output":""}. Same for cat, ls, pwd. Exit 134 is SIGABRT, so the sandboxed process aborts before the command runs. Text-only tasks (no tool calls) complete normally. With runtimeMode = "approval-required" the child does not start at all: failed to load AGENTS.md instructions: Operation not permitted.
• With default_permissions = ":workspace": {"exit_code":0,"wall_time_seconds":0.000006166,"output":"probe-ok\n"}.

Controls outside T3, same binary and config, custom profile active (no -s flag), from a terminal: codex exec -m gpt-6-sol 'Run the shell command: echo probe-ok…' returns exit 0 / probe-ok both from ~/.t3/scratch and from a linked git worktree under ~/.t3/worktrees. So the profile works for Codex on its own; it breaks only under T3's launch, where T3 applies its own sandbox settings for the child on top of the user's default profile (per #6976 the user profile is not authoritative in T3). The child's effective profile then starts with a root read grant while the user profile's first entry is ":root" = "deny". That overlap is my best guess at the trigger; not isolated further. This report is not the inheritance request from #6976: whatever T3 decides to apply, the child's shell should either run or fail with a clear configuration error, not abort every command with exit 134.

Reproduced on 2026-10-05 and 2026-10-06 across one nightly update and one Codex patch (0.160.0 → 0.160.1).

Impact

Major degradation or frequent failure (anyone with a custom default_permissions profile cannot use Codex children for shell work)

Version or commit

T3 Code Nightly 0.0.46-nightly.20261005.2689 (also .2676)

Environment

macOS 26.7.1 (Apple Silicon), desktop app, Codex CLI 0.160.1 (also 0.160.0), parent thread on Claude (claude-fable-5-1). Codex binaryPath is a one-line wrapper: exec "$(readlink -f "$(command -v codex)")" "$@".

Logs or stack traces

# child's tool result, every command, custom profile as default
{"exit_code":134,"wall_time_seconds":0.000006,"output":""}
# same child, approval-required
failed to load AGENTS.md instructions: Operation not permitted
# default_permissions commented out (for completeness): Codex refuses to load
failed to load configuration: config defines `[permissions]` profiles but does not set `default_permissions`
# default_permissions = ":workspace"
{"exit_code":0,"wall_time_seconds":0.000006166,"output":"probe-ok\n"}

Workaround

Switch default_permissions to the built-in :workspace while a Codex child needs a shell, which gives up the custom deny rules. Otherwise run Codex children text-only (no tools). Direct codex exec from a terminal is unaffected.

Written with Claude Fable 5.1 through T3's MCP tools; the human owner reviewed before posting.

[juliusmarminge]

Note

Grok responding on behalf of Julius.

Triage

Thanks @kamil-koryciorz for the careful controls (:workspace vs. the custom profile, and plain codex exec), they narrowed this down a lot. From the code on main, this doesn't look limited to delegate_task; it likely affects every Codex turn when a custom permissions profile is set.

What I found

• Every Codex turn goes through buildCodexTurnStartParams in apps/server/src/orchestration-v2/Adapters/CodexAdapterV2.ts, which always sends a legacy sandboxPolicy on turn/start: auto and auto-accept-edits send workspaceWrite, approval-required sends readOnly, and full-access sends dangerFullAccess.
• Codex 0.160 treats [permissions] profiles as the current model. turn/start can select a profile with a permissions id, which can't be combined with sandboxPolicy. T3's generated V2TurnStartParams has no permissions field, so the legacy override is applied on top of default_permissions from ~/.codex/config.toml.
• That lines up with your results. :workspace is the built-in equivalent of workspace-write, so the override agrees with it. A custom profile whose first filesystem rule is ":root" = "deny" doesn't, and combining a root deny with a legacy workspace-write grant appears to drop the readable-root baseline that :minimal normally provides, which is the shape that makes macOS Seatbelt abort the shell (exit 134) with no diagnostic. A similar silent abort looks to be tracked upstream in openai/codex#39528 and openai/codex#46406.
• approval-required is the same overlay with sandboxPolicy: { type: "readOnly" }, which denies the reads Codex needs to load AGENTS.md (Operation not permitted) rather than aborting later in the shell.
• Related but separate: [Feature]: An unattended read-only mode for delegate_task Codex children (approvalPolicy: never + sandboxPolicy: readOnly) #15381 (unattended read-only Codex child), ProviderAdapterProcessError: codex #4292 (startup refusal from a conflicting managed policy), and Discussion [Feature]: Allow Codex sessions to inherit configured permission profiles #6976 (whether T3 should honor the user's profile instead of its own sandbox). This report is about the crash when the two are combined.

Likely fix area

The Codex adapter's turn-start params, for every Codex turn rather than only delegated children. Some options:

• Skip the legacy sandboxPolicy when the user has selected a permissions profile.
• Once the schema can send permissions, map T3 runtime modes onto profile ids.
• In the meantime, fail the turn with a clear configuration error instead of starting a session where every command aborts.

Which policy should win can stay with #6976. A maintainer will decide on the fix direction.