codemode: execute and plugin tool calls have no timeout, so one slow call blocks the session until interrupted #54220

Activity

1. opencode-agent commented on Oct 10, 2026

   

   opencode-agentBot

   on Oct 10, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks for the detailed write-up. I reproduced this with opencode-drive and the simulated model. As a stand-in for your plugin, I attached a Code Mode tool slow_wait (options.codemode: true) that never returns. The model then calls execute with your two-call script.

   • @opencode/cli 2.0.26: after 150 s the TUI still showed execute › slow_wait [seconds=600] with a spinner and no elapsed time. No deadline fired. Pressing Esc ended the whole step as interrupted, with both rows marked as errors.
   • Latest v2 from source (8eff035): same result.

   The code matches your analysis. createCodeMode in packages/core/src/codemode/tool.ts calls CodeMode.make without limits, and the MCP callTool drops progress and uses the 12-hour default.

   The screenshots below come from the 150 s run on source. The recording is a shorter 5 s run of the same script on 2.0.26: it shows the flow but not the long wait. In the 150 s runs the drive tool got stuck after the interrupt and never saved the video.

   recording.mp4

   

   

   Reproduction script (drive.ts)

   // Repro for #54220: a Code Mode `execute` script awaiting a slow (never-finishing)
   // codemode-enabled tool has no deadline; the session stays busy until interrupted.
   import { Effect } from "effect"
   import { Llm, OpenCodeDriver } from "opencode-drive"
   
   const WAIT_SECONDS = Number(process.env.WAIT_SECONDS ?? 90)
   
   export default OpenCodeDriver.use(
     {
       ...(process.env.OC_DEV ? { opencode: { dev: process.env.OC_DEV } } : {}),
       tui: { recording: true },
     },
     ({ tools, llm, ui }) =>
       Effect.gen(function* () {
         // Stand-in for a slow plugin tool exposed to Code Mode (options.codemode: true).
         yield* tools.attach({
           tools: [
             {
               name: "slow_wait",
               description: "Waits for the given number of seconds.",
               inputSchema: {
                 type: "object",
                 properties: { seconds: { type: "number" } },
                 required: ["seconds"],
               },
               options: { codemode: true },
             },
           ],
         })
         yield* llm.queue(
           Llm.toolCall({
             index: 0,
             id: "call_execute",
             name: "execute",
             input: {
               code: "await tools.slow_wait({ seconds: 600 })\nreturn await tools.slow_wait({ seconds: 600 })",
             },
           }),
           Llm.finish("tool-calls"),
         )
         yield* ui.submit("Run the slow tool through execute")
         // The nested call reaches the tool and is never settled (like a slow tool).
         const call = yield* tools.take().pipe(Effect.timeout("60 seconds"), Effect.option)
         yield* Effect.log(`nested call claimed: ${call._tag}`)
         yield* ui.screenshot("t0-running")
         yield* Effect.sleep(`${WAIT_SECONDS} seconds`)
         // Still running with only a spinner: no deadline, no elapsed time.
         yield* ui.screenshot(`t${WAIT_SECONDS}-still-running`)
         const frame = yield* ui.capture()
         yield* Effect.log("\n" + (frame as any).lines.map((l: any) => l.spans.map((x: any) => x.text).join("")).join("\n"))
         // Only way out: interrupt the whole step.
         yield* ui.press("escape")
         yield* ui.press("escape")
         yield* Effect.sleep("3 seconds")
         yield* ui.screenshot("after-interrupt")
       }),
   )

   Run it with opencode-drive: opencode-drive run ./drive.ts. It drives opencode from your PATH; set OC_DEV to the path of an OpenCode checkout to run that from source instead.
2. opencode-agent

   added

   reproduced

   on Oct 10, 2026
3. Dante-dan commented on Oct 10, 2026

   

   Dante-dan

   on Oct 10, 2026

   Contributor

   More actions

   I’d build on the existing interpreter timeout, rather than add a second competing timeout around execute. On current v2, executeProgram already preserves logs/tool-call records on TimeoutExceeded; the separate gap is bounding ordinary plugin invocations at the tool boundary.

   Proposed contract:

   1. Supply the configured Code Mode budget to the interpreter. Use your suggested 10-minute default as the starting point for core review, with global/per-tool overrides. Preserve completed nested-call records and logs on timeout; never automatically replay calls that may already have had side effects.
   2. Bound non-builtin tool execution in its own cancellation scope. Expiry becomes a Tool.Error, so the runner’s existing per-call failure publication settles that call rather than interrupting the whole step. Keep shell/subagent/question timing semantics. Parent execute cancellation must still interrupt its pending children. Promise plugins already expose an AbortSignal; ignoring it must not allow a late success or progress update to overwrite the timeout.
   3. Keep an absolute execution ceiling separate from an MCP idle timeout: progress may reset the idle timer, never the ceiling. Forward progress into a nested-call slot keyed by call identity, merging with execute metadata rather than replacing its toolCalls. Expose elapsed time independently of progress messages.
   4. Permission/elicitation waits need an explicit policy. I suggest displaying them as pending and excluding their duration from the active-execution budget; cancellation must remain available. This avoids silently treating a user decision as a failed tool execution.

   Acceptance: timeout without ending the whole step, retained completed-child evidence, cooperative and abort-ignoring plugins, late-output suppression, deadline/completion races, nested progress, and permission waits. These are proposed checks, not tests I have run; the reproduction above is the bot’s.

   Would the core team approve this scope and the deadline/permission policy?