/tui and /update now refuse to restart when it would lose session state, naming the exact blocker.
What's wrong with this entry?
Before relaunching, both commands check for state that cannot be reconstructed from a restart command line: permission rules that exist only for this session, ask rules with no command-line equivalent, added directories that cannot be spelled out, and a running auto-reply monitor for artifact comments. Instead of the old generic "busy" message, they name the specific blocker and tell you what to do about it. /tui saves your renderer preference but stays where it is; /update tells you to exit and start claude again yourself.
- When the blocker is uncarriable session state, the refusal explains it is holding back because there are permission rules a command line cannot carry intact.
- When the blocker is the artifact comment monitor,
/updaterefuses with "Can't restart while auto-replying to artifact comments" and/tuiwith "Cannot switch renderers while auto-replying to artifact comments", both pointing you at/tasksto stop it. - The "saved without restart" confirmations gained matching comment-monitor wording so the reason is visible there too.
- The
tengu_update_refusedandtengu_tui_refusedtelemetry events gained fields for what was uncarriable, acomment_monitorfield, adeferredfield, and a count of active tasks in a field that previously held only a yes/no.
permission rules a command line cannot carry intact, Can't restart while auto-replying to artifact comments
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.235
Slash-command arguments are redacted before they appear in the transcript
Both mention slash command
-
v2.1.236
Pressing Enter on a typed slash command runs it
Both mention slash command
-
v2.1.238
Ctrl-C no longer wipes a slash-command rename
Both mention slash command