Expose active background shells in chat state

[Anthony Kim (anthonykim1)]

• Add BackgroundShellInfo for shell commands that keep running after their tool call returns: id, description, command, status, startedAt, and attachmentMode.
• Add BackgroundShellStatus (running / idle) and BackgroundShellAttachmentMode (attached / detached), both @nonexhaustive.
• Add optional ChatState.backgroundShells, mirrored into ChatSummary.backgroundShells through session/chatUpdated, so session subscribers can see background work without subscribing to every chat.
• Add server-only chat/backgroundShellSet (upsert by id) and chat/backgroundShellRemoved (remove by shellId, no-op when absent), introduced in 0.9.0.
• Keep the collection independent of turn lifetime. Turn completion, cancellation, steering, and truncation do not clear it, and hosts reconcile against the runtime after a chat is restored.
• Distinguish a missing collection (nothing published yet) from an empty one (no active shells). The Go generator treats backgroundShells as presence-sensitive so an empty list is not dropped.
• Keep terminal output, process controls, and turn-completion rules out of scope.
• Regenerate the schema and every client, and add reducer fixtures for add, replace, remove, absent remove, and summary mirror and clear.

Validated with npm run generate and npm test (477 tests, 100% reducer coverage).

---

Inspirations from:

• Set / Removed naming and reducer behavior follow the keyed-collection convention in general-instructions.instructions.md.
• The reducer shape is copied semantically from ChatWorkingDirectorySet / ChatWorkingDirectoryRemoved.
• Mirroring a chat-owned list from ChatState into ChatSummary follows workingDirectories in ChatState and ChatSummary.
• The presence-sensitive Go collection follows the existing AutomationDefinitionPatch handling in generate-go.ts.

[Connor Peet (connor4312)]

I wonder if this is the right approach, or if we should have a generic 'things that will wake up this chat' collection, which would include async subagents, possibly MCP tasks, etc. What do you think? cc Sandeep Somavarapu (@sandy081)

[Anthony Kim (anthonykim1)]

Great point,
Are we talking about something like:

export const enum BackgroundWorkKind {
  Shell = 'shell',
  Subagent = 'subagent',
  McpTask = 'mcpTask',
}

[Connor Peet (connor4312)]

Yea

[Anthony Kim (anthonykim1)]

PR attempting above approach ---> #482

Would love to get feedback on #482 Connor Peet (@connor4312), roblourens Sandeep Somavarapu (@sandy081)

[Anthony Kim (anthonykim1)]

Moving to ----> #482

[Anders (engstromloboz-sys)]

https://m.facebook.com/login/identify/?next=https%3A%2F%2Fm.facebook.com%2Fajay.kapsime%2522%2C%2522%3Fwtsid%3Drdr_0alfWEIqImpdQditY#