Shell tool hangs forever when the command contains a NUL character #51351

Activity

1. github-actions

   assigned

   jlongster

   on Sep 25, 2026
2. github-actions commented on Sep 25, 2026

   

   github-actionsBot

   on Sep 25, 2026 – with GitHub Actions

   Contributor

   More actions

   ---

   This issue might be a duplicate of existing issues. Please check:

   • #49997: null bytes in shell-related paths cause /api/location and /api/fs/list failures.
   • #48838: shell creation can remain pending in Shell.create before the readiness handoff.
   • #50424: a shell tool call remains status=running indefinitely after a command exits.
3. kernel-oops commented on Sep 25, 2026

   

   kernel-oops

   on Sep 25, 2026

   ContributorAuthor

   More actions

   Checked the three suggestions; none is this bug, though #48838 is in the same spot:

   • v2: interrupting the shell tool while command creation is pending can orphan the process manager #48838 is the other side of the same ready handoff in Shell.create: the caller is interrupted while waiting, and the process manager it forked is left running. Here the manager dies (a defect from spawn throwing synchronously on the NUL) without settling ready, so the caller waits forever. The fix in fix(core): fail shell create instead of hanging when spawn dies #51352 settles ready on a defect, which doesn't address v2: interrupting the shell tool while command creation is pending can orphan the process manager #48838's ownership gap.
   • Shell tool stays status=running after a fast-exiting command with no surviving descendant (1.18.30, server mode) #50424 is v1 (1.18.30): the process ran and exited, but the call stayed running. Here no process is ever started.
   • cli: opencode always opens ~ instead of requested directory (/api/location 500 with null-byte shell path) #49997 (closed) is NUL bytes in a stored shell path breaking mkdir in /api/location; it's a different code path, though it shows NUL bytes do reach spawn-related inputs in practice.
4. opencodejr commented on Oct 28, 2026

   

   opencodejrBot

   on Oct 28, 2026

   Contributor

   More actions

   Thanks for the detailed report. I could reproduce this on v2.0.16.

   In the test, a simulated model called the shell tool with printf 'a<U+0000>b' (a literal NUL) and timeout: 2000:

   • NUL command: after 25 seconds the call still had not finished, the timeout never fired and the turn never continued. Only interrupting the turn ended it.
   • Same command without the NUL (printf 'ab'): the call finished at once.

   The script below reproduces it (set CONTROL=1 for the run without the NUL). While the NUL call was stuck, the TUI also stopped answering screenshot requests, so there is no recording.

   I could not confirm the behaviour on the latest dev (86ce19d) at runtime, because my test setup did not reach the shell tool there. The part of packages/core/src/shell.ts you point to, which only handles AppProcessError before ready is settled, looks unchanged on dev, so it is probably still affected. Related: your earlier fix PR #51352 was closed by the automatic cleanup of old PRs, not after a review.

   Reproduction script (drive.ts)

   // Repro for #51351: a shell tool call whose command contains U+0000 never finishes.
   // The model calls `shell` with a 2000 ms timeout; if the call settled (error or
   // timeout), the model's follow-up text "AFTER_SHELL" would appear. It never does.
   import { Effect } from "effect"
   import { Llm, OpenCodeDriver } from "opencode-drive"
   
   export default OpenCodeDriver.use(
     {
       ...(process.env.OC_DEV ? { opencode: { dev: process.env.OC_DEV } } : {}),
       config: { permission: { "*": "allow" } } as any,
       tui: { recording: !process.env.NOREC },
     },
     ({ ui, llm }) =>
       Effect.gen(function* () {
         yield* llm.queue(
           Llm.toolCall({
             index: 0,
             id: "call_nul",
             name: "shell",
             input: { command: process.env.CONTROL ? "printf 'ab'" : "printf 'a\u0000b'", timeout: 2000 },
           }),
           Llm.finish("tool-calls"),
         )
         yield* llm.queue(Llm.text("AFTER_SHELL: the shell call settled."))
         yield* Effect.log("submitting")
         yield* ui.submit("Run printf with a NUL byte")
         yield* Effect.log("submitted")
         yield* Effect.sleep(5000)
         yield* Effect.log("slept")
         // The timeout is 2 s; give it 10x that.
         const settled = yield* ui.waitFor("AFTER_SHELL", { timeout: 20000 }).pipe(
           Effect.as(true),
           Effect.catchTag("UiWaitTimeoutError", () => Effect.succeed(false)),
         )
         yield* Effect.log(settled ? "RESULT: shell call settled (not reproduced)" : "RESULT: shell call still running after 25s with a 2s timeout (HANG REPRODUCED)")
         // End the stuck turn so the run can settle.
         yield* ui.press("escape")
         yield* ui.press("escape")
         yield* Effect.sleep(1500)
       }),
   )

   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.
5. opencodejr

   added

   reproduced

   on Oct 28, 2026
6. Santiago-j-s commented on Nov 4, 2026

   

   Santiago-j-s

   on Nov 4, 2026

   Last edited by Santiago-j-s

   More actions

   Confirming this on OpenCode 2.2.5, macOS/Darwin 25.5.0 arm64, using Desktop's matching bundled CLI and shared service. I reported #61838 before finding this issue; it appears to be the same bug.

   Here is a small reproduction through /api/shell that does not require a model or opencode-drive. Replace opencode with the Desktop-bundled CLI path if needed:

   import json
   import subprocess
   import time
   
   payload = {"command": "printf probe" + chr(0), "shell": "/bin/zsh", "timeout": 500}
   started = time.monotonic()
   try:
       result = subprocess.run(
           ["opencode", "api", "post", "/api/shell", "--data", json.dumps(payload)],
           capture_output=True, text=True, timeout=5,
       )
       print(result.returncode, result.stdout, result.stderr)
   except subprocess.TimeoutExpired:
       print(f"No response after {time.monotonic() - started:.2f}s; client watchdog stopped CLI")

   Observed: no response after 5.01 seconds, despite the 500 ms shell timeout. A control command without the NUL returned in 0.16 seconds and exited successfully. The Python timeout is an independent watchdog stopping the client, not OpenCode enforcing its shell timeout.

   Local plugins were enabled, but this direct API reproduction bypasses the shell tool's Code Mode transform; a completely plugin-free service was not tested.

   Related: merged PR #60651 adds a typed pre-spawn NUL guard and explicitly describes this failure class. That guard is absent from the published v2.2.5 source. I have not tested the fixed development branch. Adding this reproduction and newer-version/platform confirmation here so tracking can remain on this issue; #61838 can close as a duplicate.

   ---

   Note from OpenCode: This comment was written and posted by an AI agent at the account owner’s request. The reproduction was run locally by the agent.
7. Santiago-j-s

   marked shell: NUL in command hangs startup and bypasses timeout #61838 as a duplicate of this issue on Nov 4, 2026