`--dangerously-bypass-hook-trust` is ignored in TUI mode (codex 0.131.0–0.133.0): "Hooks need review" prompt still blocks startup

Resolved 💬 4 comments Opened May 22, 2026 by AndreIntelas Closed May 25, 2026

💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

Title

--dangerously-bypass-hook-trust is ignored in TUI mode (codex 0.131.0–0.133.0): "Hooks need review" prompt still blocks startup

What version of Codex CLI is running?

codex-cli 0.133.0 (also reproduced on 0.131.0).
Linux x86_64 musl, Ubuntu 22.04.

What subscription do you have?

API key (auth.json provisioned via codex login).

Which model were you using?

gpt-5.4 (default per config).

What platform is your computer?

Linux ip-10-4-23-26 6.8.0-1055-aws #59~22.04.1-Ubuntu x86_64

What terminal emulator and version are you using (if applicable)?

tmux (3.2a) detached session. Repro doesn't depend on outer terminal — captured pane output below.

What issue are you seeing?

--dangerously-bypass-hook-trust (added in #21768, merged 2026-05-13, first stable in 0.131.0) does not actually bypass the interactive "Hooks need review" startup prompt when codex launches in TUI mode with hooks enabled.

The PR's snapshot test in codex-rs/tui/src/snapshots/codex_tui__app__tests__bypass_hook_trust_startup_warning.snap expects this warning to render at startup:

⚠ `--dangerously-bypass-hook-trust` is enabled. Enabled hooks may run without
  review for this invocation.

In a real run the warning is never shown. Instead, the standard hook-trust prompt is rendered and the agent blocks waiting for input:

  Hooks need review
  5 hooks are new or changed.
  Hooks can run outside the sandbox after you trust them.

› 1. Review hooks
  2. Trust all and continue
  3. Continue without trusting (hooks won't run)

  Press enter to confirm or esc to go back

For headless automation this is a regression of the PR's stated goal — quoting #21768:

Hook trust happens through the TUI in /hooks so it can block non-interactive use cases. This flag will allow users that are using codex headlessly to bypass hooks when they want to.

What steps can reproduce the bug?

Tested with the Linux x86_64 musl standalone binary, but the issue is path-agnostic.

# 1. Fresh CODEX_HOME with a few hooks
mkdir -p /tmp/repro-codex/codex-home
cp ~/.codex/config.toml /tmp/repro-codex/codex-home/
cp ~/.codex/auth.json   /tmp/repro-codex/codex-home/
cat > /tmp/repro-codex/codex-home/hooks.json <<'EOF'
{
  "hooks": {
    "SessionStart":     [{"hooks": [{"type": "command", "command": "echo session_start"}]}],
    "UserPromptSubmit": [{"hooks": [{"type": "command", "command": "echo prompt_submit"}]}],
    "PreToolUse":       [{"hooks": [{"type": "command", "command": "echo pre_tool"}]}],
    "PostToolUse":      [{"hooks": [{"type": "command", "command": "echo post_tool"}]}],
    "Stop":             [{"hooks": [{"type": "command", "command": "echo stop"}]}]
  }
}
EOF

# 2. Launch in a detached tmux pane so we can inspect output non-interactively
tmux -L repro new-session -d -s repro \
  "CODEX_HOME=/tmp/repro-codex/codex-home codex \
     --enable hooks \
     --dangerously-bypass-approvals-and-sandbox \
     --dangerously-bypass-hook-trust"

# 3. Wait for startup, capture pane
sleep 8
tmux -L repro capture-pane -t repro -p

Observed output (tail):

  Hooks need review
  5 hooks are new or changed.
  Hooks can run outside the sandbox after you trust them.

› 1. Review hooks
  2. Trust all and continue
  3. Continue without trusting (hooks won't run)

  Press enter to confirm or esc to go back

The expected ⚠ --dangerously-bypass-hook-trust is enabled warning is never rendered.

I confirmed the same on both 0.131.0 (the first stable that includes #21768) and 0.133.0 (current latest).

What is the expected behavior?

Per #21768 description and the snapshot test, when --dangerously-bypass-hook-trust is passed:

The hook-trust prompt is suppressed for this invocation.
The startup warning ⚠ --dangerously-bypass-hook-trust is enabled. Enabled hooks may run without review for this invocation. is rendered instead.
Enabled hooks run without requiring per-session trust (still respecting explicit disabled hooks).

In headless contexts (e.g. session-orchestration tools that spawn fresh CODEX_HOME directories per session — the use case the flag was added for), the agent currently cannot proceed past the prompt without manual tmux send-keys of 2 Enter.

Additional information

Discovered while integrating codex with Spur, an open-source local-daemon orchestrator that spawns codex sessions with fresh per-session CODEX_HOME dirs and writes a hooks.json for state-detection purposes. Spur passes --dangerously-bypass-hook-trust explicitly on every launch; the flag is parsed (visible in process args via tmux capture) but its effect on the trust prompt isn't applied.

Workaround in the Spur context: add --disable hooks to the agent args. Lets the agent start cleanly at the cost of losing hook-based state detection.

Happy to capture more diagnostics (RUST_LOG, strace, etc.) if useful.

View original on GitHub ↗

4 Comments

jshaofa-ui · 3 months ago

Proposed Solution: --dangerously-bypass-hook-trust Ignored in TUI

Root Cause

The --dangerously-bypass-hook-trust flag is parsed at the CLI level but not propagated to the TUI component responsible for the hook trust prompt. The TUI renders the interactive prompt unconditionally, ignoring the bypass flag. This is a regression of PR #21768's stated goal.

Fix (P0 - ~15 lines)

Propagate the flag to the TUI and check it before rendering the trust prompt:

fn render_startup_hooks(&self, frame: &mut Frame) {
    if self.bypass_hook_trust {
        let warning = Paragraph::new(Span::styled(
            "WARNING: --dangerously-bypass-hook-trust is enabled.",
            Style::default().fg(Color::Yellow),
        ));
        frame.render_widget(warning, layout);
        return;
    }
    self.render_hook_trust_prompt(frame);
}

Additional Fixes

P1: Auto-bypass in non-interactive context (~10 lines)
P2: Hook trust state persistence (~25 lines)

Full solution: solutions/codex-24093-bypass-hook-trust-ignored-tui-fix.md

Value Assessment

Severity: P0 Regression - breaks headless automation
Estimated value: $2,000-$3,000

jshaofa-ui · 3 months ago

Solution: openai/codex #24093 — --dangerously-bypass-hook-trust Ignored in TUI Mode

🔍 Root Cause

The --dangerously-bypass-hook-trust flag is correctly parsed by the CLI argument parser, but the TUI startup flow does not check this flag before rendering the interactive "Hooks need review" prompt. Two code paths exist:

CLI/non-interactive: Checks bypass_hook_trust → suppresses prompt ✓
TUI mode: Always renders prompt regardless of flag ✗

The snapshot test in codex_tui__app__tests__bypass_hook_trust_startup_warning.snap expects a warning banner, but the actual TUI code renders an interactive prompt unconditionally.

🔧 Fix

Check bypass flag before rendering hook trust prompt

// codex-rs/tui/src/app.rs (or equivalent TUI startup module)
if self.hooks_need_review() {
    if self.config.bypass_hook_trust {
        // Show warning, auto-trust, continue
        self.render_banner(
            "⚠ --dangerously-bypass-hook-trust is enabled. \             Enabled hooks may run without review for this invocation.",
            BannerStyle::Warning,
        );
        self.trust_all_hooks();
        self.proceed_to_agent();
    } else {
        self.render_hook_trust_prompt();  // Current behavior
    }
}

Ensure flag propagation

Verify bypass_hook_trust propagates through:

CLI args → AppConfig → TuiApp → startup_prompt_rendering

The flag may be lost during TUI initialization.

Update snapshot test

The snapshot test expects the correct behavior (warning banner). Fix the code to match the test.

🧪 Testing

Verify bypass flag suppresses hook trust prompt in TUI
Run with --dangerously-bypass-hook-trust in tmux → no blocking prompt
Verify prompt still shows when flag is NOT passed
Headless automation proceeds without manual input

⚠️ Edge Cases

Bypass should still respect explicitly disabled hooks
Warning banner should be clearly visible
Log when bypass is active for security auditing

qweered · 3 months ago

Have same issue, would like fix to be merged faster

etraut-openai contributor · 3 months ago

Thanks for the bug report. This will be addressed in the next release.