Executor version
1.6.8 (macOS ARM64; local patch verified)
How do you run Executor?
CLI
Operating system
macOS (Apple Silicon)
Integration involved
MCP plugin / Codex app-server bridge elicitation
What happened
The outbound MCP request's 60-second wall-clock timeout continues while Executor waits for an elicitation response. If a person answers after that deadline, the original tool invocation has already failed. Subsequent resume calls replay its recorded terminal outcome, so refreshing the connection cannot recover that invocation.
The original invocation also leaves its elicitation handler pending when the connection closes.
What you expected
Time spent waiting for a human elicitation response should not consume the tool's 60-second active-work budget. The original invocation should receive accept, decline, or cancel once. Closing the connection should interrupt its pending elicitation handler.
Steps to reproduce
- Invoke a tool that sends an
elicitation/create request through the app-server bridge.
- Hold the response for longer than 60 seconds. The regression tests simulate 54 minutes after confirming that the prompt has arrived.
- Answer with
accept, decline, or cancel.
Before the fix, all three delayed-response cases fail because the invocation settles before the response arrives. A separate connection-close case shows that the pending handler is not interrupted.
Diagnostics / logs
Proposed fix
Use a scoped active-work deadline enforced by an AbortSignal. Suspend it only while elicitation is pending, preserve previously elapsed active time, and count overlapping prompts. Connect the elicitation handler's lifetime to the MCP request's cancellation signal. Keep the ordinary 60-second active deadline, with no automatic acceptance or tool replay.
Relevant source: MCP invocation and execution resume.
Verification
The local patch passes nine new regression tests, the complete MCP plugin suite (308 passed, 29 existing skips), and the execution suite (73 passed). Formatting, lint, changelog checks, package typecheck and the compiled CLI build pass. The protocol test also proves that a tool still aborts after 60 seconds of active work.
After installing the local timeout repair and a separate patch adding safe startup diagnostics, a controlled service restart restored live Computer Use reads and browser navigation. This establishes operational recovery, but does not identify the exact cause of an intervening startup failure or constitute a live 54-minute approval test. The deterministic regressions establish the approval-wait defect; they do not establish the behavior of every timeout layer inside the installed Codex runtime.
Related reports #1555 and #1521 concern native prompts failing to reach the client. In this reproduction the prompt arrives, then the outbound timer expires while its answer is pending.
Before you submit
Executor version
1.6.8 (macOS ARM64; local patch verified)
How do you run Executor?
CLI
Operating system
macOS (Apple Silicon)
Integration involved
MCP plugin / Codex app-server bridge elicitation
What happened
The outbound MCP request's 60-second wall-clock timeout continues while Executor waits for an elicitation response. If a person answers after that deadline, the original tool invocation has already failed. Subsequent
resumecalls replay its recorded terminal outcome, so refreshing the connection cannot recover that invocation.The original invocation also leaves its elicitation handler pending when the connection closes.
What you expected
Time spent waiting for a human elicitation response should not consume the tool's 60-second active-work budget. The original invocation should receive accept, decline, or cancel once. Closing the connection should interrupt its pending elicitation handler.
Steps to reproduce
elicitation/createrequest through the app-server bridge.accept,decline, orcancel.Before the fix, all three delayed-response cases fail because the invocation settles before the response arrives. A separate connection-close case shows that the pending handler is not interrupted.
Diagnostics / logs
Proposed fix
Use a scoped active-work deadline enforced by an AbortSignal. Suspend it only while elicitation is pending, preserve previously elapsed active time, and count overlapping prompts. Connect the elicitation handler's lifetime to the MCP request's cancellation signal. Keep the ordinary 60-second active deadline, with no automatic acceptance or tool replay.
Relevant source: MCP invocation and execution resume.
Verification
The local patch passes nine new regression tests, the complete MCP plugin suite (308 passed, 29 existing skips), and the execution suite (73 passed). Formatting, lint, changelog checks, package typecheck and the compiled CLI build pass. The protocol test also proves that a tool still aborts after 60 seconds of active work.
After installing the local timeout repair and a separate patch adding safe startup diagnostics, a controlled service restart restored live Computer Use reads and browser navigation. This establishes operational recovery, but does not identify the exact cause of an intervening startup failure or constitute a live 54-minute approval test. The deterministic regressions establish the approval-wait defect; they do not establish the behavior of every timeout layer inside the installed Codex runtime.
Related reports #1555 and #1521 concern native prompts failing to reach the client. In this reproduction the prompt arrives, then the outbound timer expires while its answer is pending.
Before you submit