You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
bug(approval): the write-stdin approval overlay (Codex 0.151+) is never detected #64
Found by review C of #58 (Codex 0.157.1 acceptance). Blocks accepting 0.157.1.
src/parsers/ApprovalParser.ts:11–16 (APPROVAL_TITLES) lacks the overlay Codex shows when the model writes to an existing terminal:
"Would you like to send input to the existing terminal?"
the variant "Would you like to send input to terminal {process_id}?"
Upstream: codex-rs/tui/src/bottom_pane/approval_overlay.rs:256–261, ApprovalRequest::Exec with kind == WriteStdin. It is binary-verified absent in 0.150.1 and present in 0.151.0 through 0.157.1; the other four titles are still present.
The effect: detectCodexApproval returns null, so no approval event fires and codex.approval never goes live. Automation waiting on the approval hangs, and extractCodexStreamingText stops suppressing the overlay, so its option rows can leak into extracted assistant text. There is no rollout backstop: no persisted exec_approval_request exists in any version.
The fix needs a recorded 0.157.1 PTY frame of this overlay.
New evidence (W1, 2026-09-27, upstream source at tag rust-v0.157.1): this overlay is off by default in 0.157.1, so it does not block accepting 0.157.1.
Gate 1: a feature flag. The approval is requested only when the write_stdin_approval feature is enabled (core/src/unified_exec/stdin_approval.rs: !features().enabled(Feature::WriteStdinApproval) → Ok(None)). features/src/lib.rs declares that feature Stage::UnderDevelopment, default_enabled: false.
Gate 2: a retained escalation. Even with the flag on, the approval fires only for a terminal whose launch permissions differ from the current ones (escalated or with retained grants), or under strict auto-review. Plain input to a normal sandboxed terminal returns UseDefault → Ok(None).
The title. The command vector is always ["write_stdin","--session-id",<pid>,<input>], so command.get(2) always exists. In practice the title is always "Would you like to send input to terminal {pid}?"; the "existing terminal" wording is unreachable today.
The rendered overlay (upstream snapshot chatwidget/tests/snapshots/…write_stdin_approval_modal.snap):
Would you like to send input to terminal 42?
Input: "confirm\n"
› 1. Yes, proceed (y)
2. No, and tell Codex what to do differently (esc)
Press enter to confirm or esc to cancel
Why no live recording: triggering this overlay needs the under-development flag plus an escalated terminal. That means a model session with an approved escalation, which Agent Code's default launch never produces.
Plan: keep this open as a real gap, but at lower priority than #63 and #65. When it is fixed:
add the title;
parse Input: "<input>" into the command field;
test against the upstream snapshot frame.
I am removing it from agent-code#234's blocker list.
Activity
Juliusolsson05 commentedon Sep 27, 2026
New evidence (W1, 2026-09-27, upstream source at tag
rust-v0.157.1): this overlay is off by default in 0.157.1, so it does not block accepting 0.157.1.write_stdin_approvalfeature is enabled (core/src/unified_exec/stdin_approval.rs:!features().enabled(Feature::WriteStdinApproval) → Ok(None)).features/src/lib.rsdeclares that featureStage::UnderDevelopment, default_enabled: false.UseDefault → Ok(None).commandvector is always["write_stdin","--session-id",<pid>,<input>], socommand.get(2)always exists. In practice the title is always "Would you like to send input to terminal {pid}?"; the "existing terminal" wording is unreachable today.chatwidget/tests/snapshots/…write_stdin_approval_modal.snap):Why no live recording: triggering this overlay needs the under-development flag plus an escalated terminal. That means a model session with an approved escalation, which Agent Code's default launch never produces.
Plan: keep this open as a real gap, but at lower priority than #63 and #65. When it is fixed:
Input: "<input>"into the command field;I am removing it from agent-code#234's blocker list.