fix(box): helpers' permissions, self-started turns and crew in chat sessions report what the agent does

[tinhthanh]

Summary

Four bugs in how a chat (structured) Claude session reports what its agent and helpers are doing. They show up when Claude Code starts helpers (subagents) in the background. Seen on a real box with Claude Code 2.1.299; each one is fixed with a test that fails without the fix.

1. A helper's permission gets lost, and the helper waits forever (claudedriver.go)
   • Every new can_use_tool was announced as the one waiting, so the app showed the newest ask while pick answers the oldest. Saying Yes to a helper's command could allow the agent's.
   • After one answer, the driver said Started although other asks still waited, so they never showed.
   • result cleared pending, dropping asks from helpers that were still working in the background.
   • Fix:
     • claudeRequest keeps agent_id.
     • A new ask announces the oldest waiting one.
     • After an answer or a control_cancel_request, afterAsk shows the next waiting ask. If none is left, it says working while the turn runs, or finished.
     • result keeps the helpers' asks and stays waiting.
2. Another Claude in the same folder can mark a live session exited (turns.go)
   • A Claude that Shipyard didn't start, such as one in an editor or a one-off claude -p a tool runs, names no session, so resolve matched its hooks by folder.
   • Its agent.exited marked the session exited while its program was alive. enrich then reads exited-but-alive as running for good, and Stop does nothing.
   • Fix: when matching by folder, a session that knows its agent's conversation (AgentSessionID) ignores events from a different conversation. Unnamed events from its own conversation still reach it.
3. A turn Claude starts by itself shows as finished (claudedriver.go)
   • When a background helper comes back, Claude goes on in a turn no prompt started: system init, then the main agent's message_start, with no replayed prompt. The session read as done while the agent worked, with no spinner and no Stop.
   • Fix: the main agent's message_start while not busy starts a turn (Started, signal: background). Its result ends it as usual.
4. Crew keeps a helper that is back as working (transcript/host.go)
   • A background helper is marked back from a <task-notification>. In the agent-host log, that notification is a stream line of its own, {"type":"system","subtype":"task_notification","tool_use_id":…,"status":…}, and unwrapHost dropped it. The helper stayed "working", its time running on.
   • Fix: unwrapHost reads it as the transcript's enqueued <task-notification>, timed by its log entry, so helperDone marks the helper back.

Tests

• TestAHelpersPermissionWaitsUntilItIsAnswered: the stand-in Claude asks as the agent and as a helper.
  • Answering the agent shows the helper's ask, and that ask outlasts the agent's turn. Answering it finishes the session.
  • If the helper is stopped instead, its ask is withdrawn and the session settles.
• TestAnotherAgentInTheSameFolderIsNotTheSessions: another conversation's ready and exited events in the folder leave the session as it was. Its own unnamed events still reach it.
• TestATurnClaudeStartsByItselfShowsAsWorking: the states go running → finished → running → finished.
• TestAHelperIsBackWhenTheStreamSaysSo: the helper is running before the stream's notification and finished after it, with until set.
• go vet ./... passes. go test -race ./... passes except TestAttachPassesShiftEnter, the macOS od spacing issue in TestAttachPassesShiftEnter fails on macOS: BSD od spaces bytes two apart #123, which is unrelated. The docs build passes. There are changelog bullets under Unreleased.
• On a real box, with the fixes deployed:
  • A session with two background helpers asking at once showed each ask in turn and finished.
  • A self-started turn showed as working.
  • Crew showed a returned helper as back.

🤖 Generated with Claude Code

[vercel]

@tinhthanh is attempting to deploy a commit to the seanbrydonio's projects Team on Vercel.

A member of the Team first needs to authorize it.

[sean-brydon]

Thanks!