Repository navigation
fix(chat): tab status edge cases - #17
Merged
Merged
Conversation
A chat killed with SIGKILL, by the OOM killer or a fatal error cannot clear its tab status, so the tab showed "working" for good. The chat now clears it once when it starts, where a status would be sent (not with tab_status off, nor inside tmux unless it is on). untab writes through the screen's output, and a headless screen can take one, so the tab status is tested: control characters in the text, and Ctrl+Z clearing it until the chat resumes.
A !cmd that exited non-zero showed "done" on the tab: RunShell now also reports whether the command succeeded. A message put back into the input because its files could not go left the status of the answer before; it shows "failed" now, and notifies, since a queued message can fail while the user is away.
Only "off" cleared the tab from /settings: turning "on" back to "auto" inside tmux left the status it had forced through, and "on" showed nothing until the next message. The chat keeps the status it shows and, whenever the mode changes, shows it again as the new mode has it.
Choosing Edit at an approval flipped the tab from waiting to working and back several times (Choose and Edit each set and reset it), and iTerm2's Notify on Status Change alerted on each flip. The status now turns to waiting at the first question and back to working once, when the call runs or closes: approved, denied or cancelled.
GNU screen drops the tab status even with tab_status on (only tmux gets the passthrough). Document the statuses a failing !cmd and an unsent message show, that an approval stays one wait through Edit, that a settings change applies at once, and that a killed chat leaves its status until the next chat clears it.
- An approved read, write or edit turns the tab back to working as soon as it is approved, not when its block closes: the approval's answer ends the wait (Output no longer does). - A cancelled approval no longer shows working for a moment before the stopped run clears the tab. - untab checks for an output like the other writers. - docs: a leftover status is not cleared under auto inside tmux or screen either.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes for the iTerm2 tab status (OSC 21337) added in v1.10.0.
tab_status ononly gets through tmux's passthrough; screen drops the sequence either way. docs/configuration.md, docs/chat.md and CLAUDE.md now say so.!cmd: showeddone.tools.RunShellnow also returns whether the command exited 0, and a failing one showsfailed.failedand notifies (only fires when the terminal is unfocused). It is not cleared because a queued message can fail while the user is away, and it waits in the input for them.tab_statusin /settings: onlyoffwas handled, so going fromontoautoinside tmux left the forced status on the tab. The chat now remembers the current status and re-applies it under the new mode whenever the mode changes (auto in tmux clears it, off clears it, on sends it again).screenToolsnow goes towaitingat the first question and back toworkingonce, when the call's output starts or its block closes (approved, denied, cancelled). A cancelled approval still ends cleared, since the send clears on interruption. Auto-approved calls never touch it.workingforever. The chat now writes one clear at startup while the screen is up, only where a status would be sent (not withoff, nor in tmux underauto). The limitation is documented in docs/chat.md.Supporting changes: a headless
ui.Screencan take anOutputfile (for tests),untabwrites through the screen's output, and the Ctrl+Z handoff body is nowscreenModel.stop.Testing
TestTabStatusControls(ESC/BEL/C1/newlines stripped from the text),TestTabStatusSuspend(cleared on Ctrl+Z, shown again on resume),TestClearTabStatus,TestRunShellStatus, and chat-levelTestTabStatusShell,TestTabStatusNotSent,TestTabStatusApproval,TestTabStatusSettingsandTestTabStatusStartup, which read the statuses a headless chat writes.gofmt -l .is clean.go build ./... && go vet ./... && go test ./...pass, and so doesGOOS=windows go vet ./....