If a container restart kills background work, your session now wakes up and Claude is told what was lost.
tengu_ccr_orphan_restore_wake Not enough to sayNothing here resolved what this flag was doing on this version, so nothing here should be read as on or off.
This account: no value returned · anonymous baseline: no value returned · compiled default in v2.1.247: off
tengu_ccr_orphan_restore_wake_shells Not enough to sayNothing here resolved what this flag was doing on this version, so nothing here should be read as on or off.
This account: no value returned · anonymous baseline: no value returned · compiled default in v2.1.247: off
Read once, for one account on one subscription tier, against v2.1.247. It isn't a statement about your account. What a flag value here can and cannot tell you
What's wrong with this entry?
When a session is restored in print mode, background tasks that were still running before the restart (agents, monitors, shells) no longer leave the session sitting idle. Their loss now queues a notification that wakes the session and hands Claude a message stating the work is gone, that no result or further notification will arrive, and that it should re-create the work if it is still needed.
- Gated on
tengu_ccr_orphan_restore_wake, which compiles in as on, so the behaviour is live unless server config turns it off; neither this flag nor its companion existed in the previous release. - Shells are only counted among the lost tasks when the second flag
tengu_ccr_orphan_restore_wake_shellsis also on, which it is by default; with it off, only agents and monitors are reported. - Ambient tasks and tasks owned by an observer are never included.
- The wake is suppressed entirely if the turn was interrupted, a main-thread command is already queued, a deferred resume is pending, or rescue is suppressed.
- Task counts are reported on a
tengu_ccr_orphan_restore_wakeevent aswake_agent_count,wake_monitor_countandwake_shell_count.
[print.ts] Waking the session for background tasks lost to the restart, The container running this session was restarted before background work reported back:
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.234
Background task notifications arrive inside a system-reminder
Both mention background task
-
v2.1.235
Several finished background tasks now report as one line
Both mention background task
-
v2.1.236
Background-task notices no longer look like user approval
Both mention background task