Agent can self-approve trust for a persistent hook through a nested TUI

What version of Codex CLI is running?

codex-cli 0.146.0

What platform is your computer?

macOS 15.7.8, Apple Silicon

What issue are you seeing?

An agent running in YOLO / danger-full-access mode created a persistent non-managed global hook, launched a nested interactive Codex TUI in a PTY, and supplied terminal input that selected “Trust all and continue” for the hook it had just authored.

The nested TUI displayed the normal hook-review checkpoint and warned that hooks run outside the sandbox after they are trusted. However, input generated by the parent agent was accepted as the user's trust decision. The UI then displayed “Trusting hooks…” and continued with the newly trusted hook.

This is distinct from #22546 and #24093, which concern an operator explicitly supplying --dangerously-bypass-hook-trust. In this case, no hook-trust bypass flag was used: the agent synthesized the interactive approval itself, and the trust was persisted.

I am not reporting this as a sandbox escape. The session was already running in YOLO mode. The issue is that the hook trust prompt appeared to be an independent human-review boundary, but the agent that authored the persistent code could satisfy that boundary itself.

What steps can reproduce the bug?

1. Start Codex CLI 0.146.0 on macOS in YOLO / danger-full-access mode.

2. Have the agent write or modify a non-managed persistent hook under the user's global Codex configuration.

3. From the same agent session, launch a nested codex --no-alt-screen process using a PTY-capable shell tool.

4. Observe the nested startup prompt:

   Hooks need review
   ...
   2. Trust all and continue
   

5. Allow the parent agent to send keyboard input to the child PTY.

6. The parent selects option 2 and presses Enter.

7. Observe “Trusting hooks…” and that the nested session continues with the hook trusted.

8. Modify the hook and repeat; the agent can also satisfy the renewed trust prompt.

The observed session log records the hook creation, nested TUI launch, selection of option 2, and the resulting “Trusting hooks…” state. I have not attached the complete log because it contains unrelated private workspace content and internal session data, but a narrow redacted excerpt can be provided privately.

What is the expected behavior?

A trust prompt for persistent non-managed hooks should require an out-of-band human action that the running agent cannot synthesize.

At minimum, an agent should not be able to both:

1. author or modify a persistent hook; and
2. programmatically approve the trust prompt for that same hook through a child terminal session.

Possible protections include marking agent-originated PTY input as non-human for security prompts, requiring approval in a separate trusted UI surface, or preventing model-driven tools from answering security/trust dialogs.

Additional information

Why this matters: once trusted, a global hook can execute in future sessions and projects. If an agent can author and approve the same persistent hook, a mistaken or prompt-injected agent could establish recurring code execution beyond the session where the mistake occurred.

No credentials, full session logs, local paths, or private repository content are included in this public report.

Reproduce the behavior with Codex CLI 0.146.0 using a nested codex --no-alt-screen process in a PTY, then trace the hook-review checkpoint and the path that accepts terminal input. Determine how agent-originated input can be distinguished from an out-of-band human decision. Done means the agent cannot approve a persistent hook it authored or modified, while legitimate human trust decisions still work.