Tool calls have no timeout - one unsettled tool hangs the step forever (read has no bound while grep/glob/webfetch do) #53433

Activity

1. github-actions

   assigned

   kitlangton

   on Oct 5, 2026
2. github-actions

   added

   needs:complianceThis means the issue will auto-close after 2 hours.This means the issue will auto-close after 2 hours.

   and removed

   needs:complianceThis means the issue will auto-close after 2 hours.This means the issue will auto-close after 2 hours.

   on Oct 5, 2026
3. github-actions commented on Oct 5, 2026

   

   github-actionsBot

   on Oct 5, 2026 – with GitHub Actions

   Contributor

   More actions

   Thanks for updating the issue with reproduction steps and system details!
4. kylebakerio commented on Oct 26, 2026

   

   kylebakerio

   on Oct 26, 2026

   More actions

   Another data point, from v1 tools (opencode 1.18.34, opencode run, local models):

   • What hung: grep called with "path": "/src", a directory that doesn't exist, outside the project. Ripgrep started from the filesystem root, never returned, and the step waited until our harness's 2 h wall-clock cap.
   • How often: twice in ~360 runs of one model, plus one other tool hang of unknown kind in ~3,800 runs.
   • How we know: the model's last request ended with finish=tool_calls, and the proxy saw nothing after that.
   • Hard to spot: --format json writes a tool part only when the tool finishes, so the transcript shows nothing pending.
   • Our workaround: we now kill rg processes older than 10 minutes from outside. The tool then returns an error and the model carries on.

   +1 for a per-tool deadline (#54503).
5. opencodejr commented on Oct 27, 2026

   

   opencodejrBot

   on Oct 27, 2026

   More actions

   Thanks for the detailed write-up. I couldn't reproduce the stuck read here. My sandbox runs Linux, not Windows.

   What I tried, on @opencode/cli@2.0.22 with a simulated model: I had the model call read on a named pipe (FIFO) in the project that nothing writes to, which was my best guess for a read that would block forever. It didn't block. The call failed right away and the step went on.

   On the first part of the report: as far as I can tell, a tool that never settles keeping the step busy is how the code works now. There is no per-tool timeout or setting for one, so a configurable timeout would be a feature request. #51188 asks for the same thing for MCP tool calls.

   To find out why read hangs on your machine, these would help a lot:

   • The exact path arguments of the stuck read calls (for example from the session export), and whether those files were inside the project or outside it, locked by another process, or on a network or OneDrive folder.
   • Whether a permission request was waiting while the session was stuck. read can ask for permission (for example for paths outside the project), and a custom TUI host may not show that prompt, so the session would look stuck in running.
   • Whether it still happens with the default opencode TUI and without @nathwn12/oc-bifrost and oc-todo.
   • Logs from around a stuck call.

   This needs someone who can test on Windows with your setup.

   Related:

   • Configurable timeout for MCP tool calls #51188: configurable timeout for MCP tool calls.
   • [BUG]: Custom tool execution has no timeout — sync I/O freezes the agent #25360 (closed): blocking I/O in a custom tool, same symptom.