Code Mode nested exec_command ignores allow rules and require_escalated on macOS

What version of Codex CLI is running?

codex-cli 0.144.3

Which model were you using?

gpt-5.6-sol with high reasoning effort

What platform is your computer?

macOS 26.5.1 (25F80), Apple Silicon (arm64)

What issue are you seeing?

In Code Mode on macOS, shell commands are invoked through an outer functions.exec custom tool call and an inner tools.exec_command. The inner command stays under the outer Seatbelt sandbox even when:

1. it matches an explicit allow rule, or
2. it is retried with sandbox_permissions: "require_escalated".

The initial .git write failure under the workspace profile is expected because .git is a protected path. The bug is that the approved/allowed escalation does not lift that restriction.

The rollout records the nested call and an immediate failure, but no approval request/decision event for the inner command. Outer telemetry identifies only tool_name=exec.

Original affected thread: 019f5c9b-6f72-74f0-9f6d-d3fa9f743897

Effective configuration

default_permissions = "workspace"
approval_policy = "on-request"
approvals_reviewer = "auto_review"

The repository is trusted and the workspace root is writable. Global rules include:

prefix_rule(pattern=["git", "add"], decision="allow")
prefix_rule(pattern=["git", "commit", "-m"], decision="allow")

There is no local requirements.toml and no explicit .git deny rule.

What steps can reproduce the bug?

1. Start Codex on macOS with the workspace permission profile.
2. In Code Mode, invoke:

``js
const r = await tools.exec_command({
cmd: "git add --refresh -- tests/test_ui_claude_agent_stream.py",
workdir: "/Users/<user>/<repo>"
});
``

1. Observe the expected protected-path failure for .git/index.lock.
2. Retry the same inner call with:

``js
sandbox_permissions: "require_escalated",
justification: "Allow the explicitly authorized git index refresh.",
prefix_rule: ["git", "add"]
``

1. Observe the same Seatbelt denial immediately, without an approval event.

A fresh controlled nested-Codex diagnostic reproduced the propagation problem more minimally. Both the normal and escalated inner commands exited in about 0.1 seconds with:

sandbox-exec: sandbox_apply: Operation not permitted

The original thread produced:

fatal: Unable to create '/Users/<user>/<repo>/.git/index.lock': Operation not permitted

An escalated direct probe such as touch .git/codex-write-probe also remained denied.

What is the expected behavior?

A nested command matching an allow rule, or a command whose require_escalated request is approved, should execute outside the workspace Seatbelt restriction. If escalation cannot be honored through Code Mode, the inner request should be surfaced as rejected/unsupported instead of silently running with the original sandbox.

Additional information

Read-only Git operations work. The same Git binary and repository work outside the Codex shell, and GitHub Desktop can update the repository metadata normally. File ownership, ACLs, flags, stale locks, and alternate Git binaries were ruled out.

Related but distinct:

• #15505 concerns the normal protected .git behavior in workspace-write.
• #21982 concerns an app-server approval request not being surfaced; this report is specifically the Code Mode outer-exec / inner-exec_command propagation path.