# One Approval Boundary Is Enough

The second RC3 gate reached the exact state we wanted to test: the outer Host
had dropped from Full Access to Auto, and an open Codex Work Room had already
shown the narrower profile. The next task explicitly asked for Claude Code.
The parent agent announced the delegation, then waited for five minutes without
starting Claude.

Claude Code was healthy. Calling the same candidate adapter directly returned
the expected marker with exit code zero. The wait belonged to a redundant
outer approval that the release harness could not see.

`co ai` deliberately gives its Codex and Claude Code wrappers a session-local
grant. Those wrappers start managed native runtimes whose own permission
profiles govern file and command actions. Asking once more before entering the
wrapper does not add a useful boundary; it only hides the provider's real one.

Auto's deterministic classifier did not know about that narrow grant. It
classified the wrapper name as unknown, required a person, and then discarded
every reusable permission except one whose source was `user`. The managed grant
used the truthful source `safe`, so a policy intended to prevent broad config
from bypassing approval also filtered out the capability `co ai` had just
created.

The fix does not put Codex or Claude Code on a global allowlist. Auto recognizes
only the exact session grant injected by `co ai`: supported provider name,
allowed flag, safe source, managed-delegation reason, and never expiry. It
records that call as an allowed managed delegation. Config grants, near matches,
arbitrary safe reasons, and incomplete grants remain unknown and still ask.

Tests now run the deterministic Auto classifier and the human approval hook in
their real order for both wrappers. The lesson is that nested approval systems
need one explicit handoff point. Duplicating the outer dialog does not make the
inner runtime safer; it makes the authority model harder to observe and test.