Claude ACP: long-running Bash command blocks new prompts indefinitely
- Dominant language
- TypeScript
- Stars
- 909
- Forks
- 116
- Avg merge
- 1d 1h
- Merged PRs (30d)
- 156
Description
## Before filing
- [x] I searched open and closed issues for duplicates.
- [x] I reproduced this on the latest Berd release.
- [x] This report covers one bug.
## Closest existing issue
I could not find a matching Berd issue. A related upstream issue is https://github.com/agentclientprotocol/claude-agent-acp/issues/739, but that issue covers stdout not streaming during a long-running Bash command, not Berd accepting a new prompt while the active tool call is still running.
## What's broken
When a Claude ACP turn launches a non-terminating foreground Bash command such as `tail -f`, Berd keeps the chat in a running state indefinitely. A new user message sent in the same chat is appended to the transcript, but it does not interrupt or steer the active tool call and receives no assistant response.
## Steps to reproduce
1. Launch Berd 0.6.2 on macOS.
2. Open a Claude ACP chat using Opus 1M. The observed chat had prior history.
3. Have the agent start a foreground log monitor using `tail -f` or an equivalent non-terminating command.
4. While the command is still running, send another message asking the agent to stop monitoring and answer a simple question.
5. Observe that the new message appears in the transcript, but the chat remains running and no assistant response arrives until the foreground process is terminated externally.
## Expected behavior
A new user prompt should either:
- interrupt, steer, or cancel the active foreground tool call and begin the new turn; or
- be visibly queued, with a usable stop control, and run after the active command is stopped.
The chat should not silently remain blocked indefinitely.
## Actual behavior
The new message appears in the transcript, but no assistant response is produced and the chat remains in a running/streaming state. In the observed incident, the Claude ACP Bash child continued running `tail -f` for more than 12 minutes. There was no clear indication that the prompt was blocked behind the tool call.
This occurred twice on August 19, 2026. Terminating the foreground command externally, or starting/forking another chat, was required to continue.
## Frequency
Intermittently — happens often but not always.
## Berd version
0.6.2 (latest release at time of filing)
## Operating system
macOS 26.5.1 (25F80), Apple Silicon, M1 Max
## Model and provider
Claude Opus 1M via Claude ACP (`@agentclientprotocol/claude-agent-acp` 0.70.0)
## Relevant log output
No relevant error appeared in `berd.log` around the incident; it continued logging normal session-reuse activity while the chat stayed running. Runtime inspection showed that the foreground `tail -f` child process remained active for more than 12 minutes.
## Additional context
This makes an immediate follow-up appear to be ignored whenever the agent leaves a monitor or development process in the foreground. A visible queued state and reliable interrupt/stop behavior would prevent the chat from becoming effectively unusable.
Contributor guide
Research direction
Reproduce the issue in Berd 0.6.2 on macOS with a Claude ACP chat and a foreground `tail -f`, then trace the chat running state, prompt handling, and ACP Bash child lifecycle. Done means a new prompt is interrupted, steers, or is visibly queued with a usable stop control, rather than leaving the chat silently blocked.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- desktop
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100