[bug] MCP tool timeout includes elicitation wait, leaving resume to replay a terminal failure #1953

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

1. Invoke a tool that sends an elicitation/create request through the app-server bridge.
2. Hold the response for longer than 60 seconds. The regression tests simulate 54 minutes after confirming that the prompt has arrived.
3. 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

• I searched the open issues for a duplicate.
• I removed all keys, tokens, and credentials from this report.