Show background task progress between Session turns

[gjkim42]

What type of PR is this?

/kind bug

What this PR does / why we need it:

When a Claude Code Session finishes a turn while background work continues, its progress indicator disappears and only the generic Active status remains. Show the reported background-task count in the Console and interactive terminal so users can tell that work is still running.

• Between turns, show 2 background tasks running and keep the composer available for another message.
• During a turn, show the count alongside Working, Waiting for input, or Interrupting.
• Clear the indicator when the reported count reaches zero, and restore the current count on reconnect.
• Clear live activity when the Session is suspended, resetting, or not Ready, including cached views. Resuming waits for activity from the runtime.

The count comes from Claude's task lifecycle events and excludes internal housekeeping. It covers reported subagents and background commands; it does not infer that the parent is blocked on a particular task. Providers without this telemetry keep their existing turn progress display.

Before — background work continues after the parent turn

After — the same Session state

After — an active turn with one background task remaining

Screenshots use the actual Console with sample Session API responses and WebSocket events. The before/after comparison uses the same conversation and activity state; these are not captures of a live agent run.

Which issue(s) this PR is related to:

N/A

Special notes for your reviewer:

Background counts travel through the existing live runtime-status stream, outside retained conversation history. The same reported count drives Session activity and idle-drain handling. Partial model/usage updates preserve the count, and the connection snapshot includes the current value.

Validation:

• make update
• make build WHAT=cmd/kelos-session-runtime
• Full unit suite: env -u CODEX_AUTH_JSON -u CODEX_HOME make test TEST_FLAGS='-timeout=120s'
• make verify, including go vet
• Chromium checks passed for background-only activity, concurrent turns, completion, reconnect, mobile layout, suspension/resume with a delayed runtime snapshot, and an unavailable runtime
• CI: passed — build, verification, race-enabled unit and integration tests, and end-to-end tests

The unit suite unsets inherited CODEX_AUTH_JSON and CODEX_HOME because they interfere with existing entrypoint tests. E2e coverage also checks the completed background count in reconnect status.

Does this PR introduce a user-facing change?

The Console and interactive terminal show the number of reported Claude Code background tasks still running, including between turns, and restore that indicator after reconnecting.

---

Summary by cubic

Shows the reported Claude Code background-task count in the Console and interactive terminal so progress remains visible after a turn ends.

• Shows N background tasks running between turns; during a turn the count appears alongside Working, Waiting for input, or Interrupting.
• Background work alone still leaves the composer open for another message.
• Clears the indicator when the count reaches zero and restores it on reconnect; the count is also hidden while a session is suspended, resetting, or not Ready.
• Background activity now derives from this count; the old provider.background event is removed.
• Providers that don't report a count keep the existing turn progress indicator.

^{Written for commit d3e6a82. Summary will update on new commits.}

[cubic-dev-ai]

All reported issues were addressed across 12 files

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[gjkim42]

/kelos review

[kelos-bot]

🤖 Kelos Task Status

Task kelos-reviewer-issue-comment-0878aed358b5 has succeeded. ✅

[kelos-bot]

🤖 Kelos Reviewer Agent @gjkim42

Review Summary

Verdict: APPROVE
Overall correctness: patch is correct
Scope: Sends Claude Code's background-task count through the runtime-status stream so the Console and terminal show it between turns and next to Working/Waiting for input/Interrupting. The same count now decides Session activity and idle drain.

Findings Overview

Priority	Count	File:Line	Summary
P0	0	—	none
P1	0	—	none
P2	0	—	none
P3	1	internal/consoleserver/frontend/app.ts:1526	Console keeps showing "N background tasks running" after the Session is suspended

Findings

Correctness

• [P3] internal/consoleserver/frontend/app.ts:1526 — The background indicator is driven by state.runtimeStatus.backgroundTasks. Nothing clears that value when the Session stops being Ready. suspendSession() and the becameNotReady branch of the session-list poll call closeSocket(), and neither one resets state.runtimeStatus or calls refreshSessionProgress(). This is a likely user path: the docs say long-running Claude Code tasks (dev servers, watchers) block idle suspension, so a user may suspend the Session manually while the count is still >0. The Console then keeps showing "1 background task running" next to the Suspended state, even though the runtime is gone (the docs say background work "does not survive stopping or replacing that runtime"). The indicator clears only on resume, when the new runtime's snapshot replaces runtimeStatus. A page reload also clears it, because cached Session views live only in memory. A stale activeTurn has the same gap today, but background tasks are the common case for a manual suspend. Possible fix: clear the background count (or hide progress) when the selected Session is not Ready or is resetting.

Suggestions (optional)

• [P3] internal/cli/session_terminal_tui.go:950 — When only background tasks are running, progressVisible() keeps the one-second progress tick going even though the label has no elapsed time to update. The cost is negligible. If you touch this code again, scheduleProgress() could skip ticking in that state and rely on the runtime.status events to re-render.

Key takeaways (optional)

• The runtime changes hold together. Count changes go through updateProviderRuntimeStatus (bypassing the shell/turn-completion deferral the same way the removed provider.background event did). Partial model and usage updates leave the count unchanged, and cloneRuntimeStatus deep-copies the new pointer. The reconnect snapshot carries the count, which is never written to the journal.
• backgroundActive is now set from the count under runtimeStatusMu. The publish and update-report signals still fire after the lock is released, with the same lock order as before, so idle drain and Session activity behave as they did.
• The tests cover count transitions (duplicate start and unknown task id), streaming plus reconnect plus partial updates, exclusion of housekeeping tasks, the TUI labels and composer height, and the Console labels, view switching and reconnect. The e2e test checks for a count of 0 after the background follow-up. That is reliable because the fake Claude sends task_notification before the follow-up text.

[gjkim42]

Addressed the Kelos review in 6c0dd87.

• Fixed the stale Console progress finding. Progress requires a Ready Session that is neither resetting nor user-suspended, and header/lifecycle updates refresh it immediately. Cached views respect the same condition, and hidden progress stops its elapsed-time timer.
• Added coverage for manual suspension, polling transitions, cached views, and both foreground and background activity. Chromium checks also passed for suspension/resume and an unavailable runtime.
• Deferred the optional terminal tick optimization: the review identifies its cost as negligible, and it does not affect the progress state or correctness.

make update, the full local unit suite, and make verify passed. The branch is squashed to one commit, and CI is running for the updated head.

[cubic-dev-ai]

All reported issues were addressed across 4 files (changes from recent commits).

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic</sub>