Decide V2 MCP elicitation timeout semantics #35275

Context

V2 MCP tool calls can trigger MCP elicitation/create requests that wait on human input. We need to decide what timeout semantics should apply while the user is filling out an elicitation form.

The immediate problem is that MCP client libraries may apply default request timeouts to the outer tools/call request. If the server asks for user input during that request, the tool invocation can time out before the user answers.

Decision Needed

We should decide whether V2 MCP tool-call timeouts should:

1. Be effectively disabled for tools/call, relying only on opencode interruption/cancellation.
2. Use a long finite timeout for tools/call.
3. Track active execution time separately from human-wait time, so elicitation pauses timeout accounting.
4. Use another explicit policy/config surface for MCP tool timeout behavior.

Prior Art

Codex has explicit handling for this shape: MCP tool calls can have a configured timeout, but timeout accounting pauses while an elicitation is pending. If no tool timeout is configured, the call awaits normally. This separates server execution time from human response time.

Notes

The important distinction is that tools/list/catalog request timeouts are not the same as tools/call timeout semantics. This issue is specifically about long-running MCP tool invocations that block on user elicitation.