Interactive Bash tool hangs after successful execution; tool_result is not written to session/UI

[cryptoya]

Summary

In Claude Code interactive mode, every Bash tool call gets stuck at Running... / reports an internal error and never returns output to the UI. The same Bash commands work in non-interactive mode (claude -p). Debug logs show that the local Bash command is actually executed successfully (tool_dispatch_end outcome=ok), but the corresponding tool_result is never written back to the session JSONL or rendered in the interactive UI.

This looks like an interactive-mode tool-result handling / streaming / session-state bug rather than a shell startup failure.

Environment

• Claude Code version: 2.1.119
• OS: macOS / Darwin 25.3.0
• Default shell: /bin/zsh
• Also reproduced after forcing Bash via Claude settings:
  • SHELL=/bin/bash
  • CLAUDE_CODE_SHELL=/bin/bash
  • CLAUDE_BASH_NO_LOGIN=1
• Claude Code is configured through a local proxy at http://127.0.0.1:5000.
• Provider format that works for normal requests: OpenAI-compatible chat/completions.

What Works

Running Bash through non-interactive mode works and returns output, for example:

claude -p 'run pwd with Bash'

The command executes and returns normally.

What Fails

In interactive mode:

claude

Then ask Claude Code to run any Bash command, for example:

pwd

The UI shows the Bash tool as running, but it never surfaces the command output and the conversation does not continue normally. In some cases Claude Code reports an internal error.

This happens for all Bash commands tested, including trivial commands such as pwd, echo hi, and ls.

Debug Evidence

Using --debug-file, the debug log shows that the Bash tool is dispatched and completes successfully locally. The key observation is:

tool_dispatch_start ... tool_name=Bash ...
tool_dispatch_end ... outcome=ok ...

So shell process creation and command execution appear to succeed.

However, after this successful tool_dispatch_end outcome=ok, the expected tool result is not persisted into the session JSONL file. The session file does not contain the corresponding tool_result, and the interactive UI remains stuck at Running... without displaying the Bash output.

Things Already Tried

• Verified claude -p non-interactive mode works.
• Reproduced in interactive mode with claude.
• Reproduced with claude --bare.
• Reproduced in a clean temporary directory.
• Disabled MCP servers for the test.
• Forced Claude Code to use /bin/bash instead of zsh.
• Verified debug logs show Using shell override: /bin/bash.
• Reviewed shell startup files (~/.zshrc, ~/.zprofile, etc.). No obvious non-interactive shell pollution was found; ~/.zshrc has an interactive guard like [[ $- != *i* ]] && return.
• Disabled or adjusted several Claude Code environment flags related to prompt caching, telemetry/error reporting, experimental betas, background tasks, and fine-grained tool streaming. The issue persisted.
• Confirmed that switching the proxy to native Anthropic format is not viable in this environment because the upstream rejects some Claude Messages API fields such as context_management; the OpenAI-compatible format is required for normal requests.

Expected Behavior

After the Bash subprocess completes successfully, Claude Code interactive mode should write a tool_result event to the session, render the Bash output in the UI, and continue the conversation.

Actual Behavior

The Bash subprocess appears to complete successfully according to debug logs, but the tool result is lost before it reaches the interactive UI/session state. The UI remains stuck at Running... or eventually reports an internal error.

Why I Think This Is a Claude Code Interactive-Mode Bug

The strongest signal is that tool_dispatch_end outcome=ok is present in the debug log, while the corresponding tool_result is missing from the session JSONL and the UI. This suggests the shell execution path itself is working, but the interactive-mode result propagation path is failing after successful tool execution.

This may be related to streaming/tool-result handling in interactive mode, especially when using an OpenAI-compatible proxy, but the failure point appears to be inside Claude Code after local Bash execution succeeds.

Related Issues

Possibly related:

• [Bug] Bash commands not executing - unclear error messaging for environment issues #47138
• [BUG] Bash Commands do not execute, Return No Output #41722

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] All tool executions failing #53783
2. [BUG] Claude Code CLI hangs indefinitely after a successful tool_use response is lost in streaming receive #53328
3. [BUG] Tool results silently dropped with "missing due to internal error" across all tools on Windows (regression in 2.1.101) #46767

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[0xbrainkid]

This bug is subtle but important because it severs execution truth from user-visible truth.

If interactive Bash succeeds but then hangs before writing tool_result to the session/UI, the user is left with the worst possible state: the underlying action may already have happened, but the visible record suggests uncertainty or failure.

That makes it a state-legibility problem, not just a hang.

The consequences are messy:

• users may retry commands that already succeeded
• debugging becomes harder because the durable record is missing the decisive event
• trust drops because the tool boundary no longer tells the truth about what the system actually did

I would want this investigated around completion signaling:

1. does the subprocess finish and only the reporting path hang?
2. is the tool_result write blocked on PTY/flush behavior after command success?
3. can the UI distinguish “execution finished, reporting incomplete” from “execution still running”?

A system can recover from a failed command. It is much harder to recover from a command that succeeded while the interface failed to say so, because that breaks the operator’s model of the run itself.

[cryptoya]

This bug is subtle but important because it severs execution truth from user-visible truth.

If interactive Bash succeeds but then hangs before writing tool_result to the session/UI, the user is left with the worst possible state: the underlying action may already have happened, but the visible record suggests uncertainty or failure.

That makes it a state-legibility problem, not just a hang.

The consequences are messy:

• users may retry commands that already succeeded
• debugging becomes harder because the durable record is missing the decisive event
• trust drops because the tool boundary no longer tells the truth about what the system actually did

I would want this investigated around completion signaling:

1. does the subprocess finish and only the reporting path hang?
2. is the tool_result write blocked on PTY/flush behavior after command success?
3. can the UI distinguish “execution finished, reporting incomplete” from “execution still running”?

A system can recover from a failed command. It is much harder to recover from a command that succeeded while the interface failed to say so, because that breaks the operator’s model of the run itself.

Thanks, this captures the risk very well.

I agree that the most important part is not just that the UI hangs, but that the execution boundary becomes ambiguous. From the debug logs, the subprocess appears to finish successfully (tool_dispatch_end outcome=ok), but the result does not make it into the durable session record or the UI.

That creates exactly the dangerous state you described: the command may already have mutated the system, while the operator has no reliable visible confirmation.

I think the key thing to investigate is the handoff after local tool completion:

1. Bash subprocess completes successfully.
2. Claude Code records tool_dispatch_end outcome=ok.
3. Somewhere between that point and writing/rendering tool_result, the interactive session stalls.

So the bug may be less about shell execution itself and more about completion propagation: result serialization, PTY/output flushing, stream handling, or session-state persistence. Even a fallback state like “command finished, but result reporting failed” would be much safer than leaving the UI in “still running”.

[jonpepler]

Confirming on macOS 26.4.1 / Claude Code 2.1.139 / zsh. Same symptom (tool_dispatch_end outcome=ok, tool_result never reaches session/UI), but worth noting it's intermittent and seemingly random in my case — not every Bash call. Most run fine; a small unpredictable fraction get dropped. Frequency is low enough that a 2-day trace of ~140 wrapped calls captured zero hangs in the log, even though I've hit several in the same window via interactive use. No clear correlation with command length, runtime, output size, or command type — short greps drop just as often as long test runs.

Three additional data points from a debugging session today:

1. run_in_background: true calls leave orphan polling shells alive indefinitely. The harness spawns zsh -c 'until [ -s <task>.output ]; do sleep N; done; cat <task>.output' to wait on the backgrounded job's output. When the relay drops, that shell sits there forever — I just found three on a single frozen session, one >26h elapsed, all PIDs still in ps. From a sibling Claude Code session, writing into the empty *.output file causes the polling shell to exit cleanly (the [ -s ] test passes, cat runs, shell terminates). But the orphaned session still doesn't surface the injected message — consistent with the result-delivery drop being upstream of the shell exit.

2. One polling variant has a self-match bug. Some backgrounded calls poll on until ! pgrep -af "<thing>"; do sleep N; done, and the spawned shell's own argv contains "<thing>" verbatim, so pgrep matches itself and the negation is never true. That shell polls forever even when the target process exited days ago. Trivially fixed with a bracket character ([<first-char>]rest) in the poller generator.

3. Remote-cancel from a sibling session is not viable. Two attempts:

• TIOCSTI ioctl into the frozen Claude's /dev/ttysNNN to inject \x03: PermissionError: Operation not permitted on macOS 26 without sudo. (TIOCSTI has been progressively locked down on BSD/macOS for security.)
• External kill -INT <claude-pid>: kills the entire Claude process. The TUI is in raw mode, so in-app Ctrl+C is handled as a keystroke at the application layer, not a kernel signal — no signal-level cancel-tool path exists. Only physical Ctrl+C in the host terminal works.

Local workaround is wrapping every Bash call with perl -e 'alarm shift; exec @ARGV' SECONDS … + run_in_background: true + a ScheduleWakeup, so the model survives the drop. The shell really does finish in every traced case (no alarm-fired exits), confirming the bug is in the post-completion delivery path, not the shell itself.

[github-actions]

Closing for now — inactive for too long. Please open a new issue if this is still relevant.