Buffer becomes read-only after response: shell-maker--busy stuck at t with no active request

[madorian]

Description

After a response completes, the buffer becomes entirely read-only. Typing anywhere produces Text is read-only. The session is unrecoverable without killing the buffer.

This is not #510 (unhandled notification) — no unhandled notification is visible. The response simply ends and no prompt is inserted.

Diagnostic Data

Collected from the stuck buffer via emacsclient -e:

• shell-maker--busy: t — shell-maker thinks it is still processing a request
• shell-maker--request-process: nil — no active request process exists
• comint-last-prompt: nil — no prompt was tracked by comint
• No prompt regexp match at buffer end
• Last character has text properties (read-only t front-sticky (read-only) field output), blocking all insertion
• ACP process itself is alive (process-status: run)

Root Cause Hypothesis

The request/response cycle completed (or errored), shell-maker--request-process was cleared, but shell-maker--busy was never reset to nil. Because shell-maker still considers itself busy, it never inserts a new prompt. The front-sticky (read-only) property on the last output character then prevents any input.

Reproduction

Intermittent — happens occasionally after a response finishes. No reliable reproduction sequence found. Backend is Claude Code via ACP.

Environment

• agent-shell: 1e5d175 (includes 794cb1c fix for agent-shell enters frozen/hanging state when receiving unknown notifications related to ACP's Session Usage RFD #455)
• shell-maker: 6377cbd
• Emacs 30.2 on NixOS
• Backend: Claude Code (ACP)
• Terminal: emacs -nw (over SSH)

[madorian]

Additional data — this is reproducible and happens on every response in some sessions, not just once.

Second occurrence (different variant)

Unlike the original report where shell-maker--busy was stuck at t, in this variant:

• shell-maker--busy: nil (not stuck)
• shell-maker--request-process: nil
• comint-last-prompt IS set correctly (markers point at Claude> )
• The prompt is present at the end of the buffer

The problem: every response leaves two trailing newlines after the prompt with (read-only t front-sticky (read-only) field output) text properties. The prompt text itself is fine, but these two extra newline characters block all input.

Buffer state:

last chars: "...Claude> \n\n"
props@(1- point-max): (field output fontified t front-sticky (read-only) read-only t)
props@point-max: nil

Manually removing the read-only property from the trailing newlines unblocks input, but the problem recurs on the next response.

Environment

Same as original report (agent-shell 1e5d175, shell-maker 6377cbd, Claude Code 2.1.104, Emacs 30.2, NixOS, emacs -nw over SSH).

[kartsm]

I have experienced this problem as well.

• macOS Sequoia 15.7.4, Apple M3 silicon
• Emacs 30.2 via Homebrew, local, graphical
• agent-shell 20260408.1635 (according to *Packages*)
• shell-maker 20260330.851
• OpenCode 1.4.0 via Homebrew