feat: "waiting" status for threads with open background tasks (i.e. pr monitors) by t3dotgg · Pull Request #4415 · pingdotgg/t3code

t3dotgg · 2026-07-24T01:12:04Z

When the agent stops while background tasks (subagents, background bash, monitors) are still running, the sidebar showed Done, then flicked back to Working when a task completion woke the agent (median 13s later, from local history).

Now ingestion tracks provider-reported open tasks per thread and parks the session on the previously-unused idle status when a turn ends with tasks still open. Sidebar v2 (web + mobile) renders it as a grey Waiting label with the same elapsed timer as Working; the row recedes like other in-flight states. Waiting flips directly to Working on wake-up — no intermediate Done.

Task set is keyed by provider instance and cleared on exit/stop/error, so stale tasks can't park a fresh session.
idle was already handled as "resting" by settlement, projection, and phase logic, so no contract or migration changes; old clients degrade to today's behavior.
Codex/OpenCode don't emit task events — behavior unchanged there.

🤖 Generated with Claude Code

Note

Medium Risk
Changes core session lifecycle in ProviderRuntimeIngestion (when threads show ready vs idle), with broad integration tests but no contract migration—incorrect task tracking could mislabel thread state across clients.

Overview
Threads that finish a turn while provider background tasks (monitors, subagents, etc.) are still open no longer flash Done before the wake-up turn. Provider runtime ingestion now tracks open tasks per thread and provider instance and parks the session on idle instead of ready when a turn ends with tasks still open; task state is cleared on session exit, error, and stale-instance guards, with tombstones for late events.

Web sidebar v2 and the mobile thread list map idle to a muted Waiting label (same elapsed timer as Working, in-flight row treatment). Successful task completion is expected to wake the agent without an intermediate ready; only a stopped last task returns Waiting to ready.

^{Reviewed by Cursor Bugbot for commit 368e0e1. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Add 'waiting' status for threads with open background tasks

Introduces a new idle session status that signals a thread is waiting on background tasks (e.g. PR monitors) rather than active user input or processing.
ProviderRuntimeIngestion tracks open tasks per thread/provider instance and transitions sessions to idle at rest when tasks remain open, returning to ready when the last task completes.
The web sidebar and mobile thread list both render idle sessions as 'Waiting' with a neutral style and an elapsed duration, treated as in-flight for display purposes.
Open task state is cleared on session exit or error so future sessions do not inherit the waiting state.
Behavioral Change: threads that previously resolved to ready while background tasks were open will now show as waiting until those tasks complete.

^{Macroscope summarized 368e0e1.}

coderabbitai · 2026-07-24T01:12:12Z

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 91fb2c98-8548-4670-a2cd-2cbb6e8a3eee

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

Create PR with unit tests
Commit unit tests in branch t3code/sidebar-waiting-state

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

macroscopeapp · 2026-07-24T01:16:45Z

Approvability

Verdict: Needs human review

New feature introducing a 'waiting' status with non-trivial server-side state tracking logic for background tasks. While well-tested, new user-facing behavior and runtime session status changes warrant human review.

^{You can customize Macroscope's approvability policy. Learn more.}

When the agent stops with background tasks (subagents, background bash, monitors) still running, the thread showed Done, then flicked back to Working when a task completion woke the agent. Track provider-reported open tasks in ingestion and park the session on the previously-unused "idle" status; sidebar v2 renders it as a grey "Waiting" with the same elapsed timer as Working. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Review fixes: gate the terminal-status task sweep behind the lifecycle guard so rejected stale events cannot erase the active turn's tasks; ignore task starts from a provider instance that doesn't match the projected session instead of letting them displace the current set; tombstone completed task ids so late/duplicate progress cannot re-open a finished task and park the thread on Waiting. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

A completed/failed final task wakes the agent (its notification is the wake signal), so Waiting flips straight to Working. A stopped final task is a kill — no wake follows — and previously left a live session parked on Waiting until teardown. Flip that case back to ready, and tombstone completions that outrun their start event. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

cursor

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 514fccf. Configure here.}

Tombstones exist to stop late/duplicate progress from resurrecting a finished task, but providers reuse task ids when an agent is resumed — a fresh task.started after completion is real work, not a replay. Progress stays blocked by the tombstone; an explicit start clears it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Real-data feedback round two: - Results render as a responsive grid (1/2/3 columns) instead of a full-width list. - While the sweep runs, the page shows only a progress count ("Reviewing your work — 7 of 18"); results reveal all at once when every thread is done, so triage happens in one pass over a stable layout instead of chasing cards as they pop in. - The model now returns a one-sentence imperative nextStep ("Review and merge PR #4415.") which becomes the card body — a direct answer to "what should I do here". Summaries are capped at one sentence and demoted to an info-icon tooltip. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…2.1-next Absorb CTM tip 408efa6 (Claude replay cleanup, ACP auth/fork provenance, derived-thread wake, fork-shell navigation wait) onto the pingdotgg#4415 Waiting sequence pinned at main ece0508. Conflict resolution (same intent as prior merge 616da6976): - Sidebar/threadList Waiting uses runtime.idle (CTM/orchestrator-v2 park) rather than session.idle from main pingdotgg#4415, including mobile tests. - Drop ProviderRuntimeIngestion (deleted on CTM; v2 uses orchestration-v2).

Update sidebar and mobile expectations for the pingdotgg#4415 Waiting status, repair command-suite settle/interrupt coverage after layer merges, and remove a duplicate settledAt JSON field that broke contracts typecheck.

…list The conversation timeline showed a Waiting line on desktop but nothing on iOS, and the mobile thread list showed no status at all. Mobile now derives the same normalized post-settlement background roster the server and web derive, appends the matching row to the thread feed, and gives the classic list resolver the Waiting pill its web counterpart already has. The conversation view prefers deriveThreadRuntime(projection), so activeWorkStartedAt went null at settlement and the row it gated simply vanished. The row is now driven by the roster rather than by run timing. The list gap was the same shape as the classic web sidebar gap this PR fixes: the v2 list sits behind a preference that is off, so the list that renders is the classic one, whose resolveThreadStatus had no Waiting branch. It now ranks a static muted Waiting pill below approvals, input, active work and failures, and above Plan Ready. Teaching the v2 list resolver about Waiting is pingdotgg#4415 waiting-presentation's concern, not this commit's. The derivation lives in deriveThreadPendingBackgroundWork rather than inline in the composer hook so the policy is unit tested. It passes runs, which the web call site in ChatView also passes, so turn items owned by a rolled_back run are abandoned on mobile exactly as they are on desktop. Without that argument the shared helper sees an empty rolled-back set and iOS would show Waiting where desktop does not. Working and Waiting are chosen from the parked runtime rather than from run timing alone. A successful run persists as waiting with a null completedAt until checkpoint capture lands, so deriveActiveWorkStartedAt keeps reporting a start time for that whole window; deriveThreadWorkingStartedAt suppresses it once the roster has parked the runtime at idle, which is how web sequences the two. A waiting run with an empty roster still reads Working, since that is checkpoint capture with no background work behind it. Two defensive points. Mobile restores projections from disk and shouldPersistThread persists only settled ones, so a cached projection is exactly the shape that reproduces a Waiting row for work that already finished; the roster is therefore gated on a live thread detail, and synchronizing is refused alongside cached because a subscription passes through it before any fresh projection arrives. And formatPendingBackgroundWorkLabel interpolates the raw description, which for a subagent item is the whole child prompt, so the label is clamped to two lines. Co-authored-by: codex <codex@users.noreply.github.com>

Update sidebar and mobile expectations for the pingdotgg#4415 Waiting status, repair command-suite settle/interrupt coverage after layer merges, and remove a duplicate settledAt JSON field that broke contracts typecheck.

juliusmarminge · 2026-07-30T15:37:00Z

Closing in favor of #2829 (orchestration V2).

#2829 deletes the V1 orchestration layer this PR builds on — apps/server/src/orchestration/**, provider/Layers/*Adapter.ts and provider/Services/** are removed and replaced by apps/server/src/orchestration-v2/**, with the IPC surface renamed to ORCHESTRATION_V2_WS_METHODS. The files this PR touches either no longer exist or are rewritten, so it can't be rebased — it would need reimplementing against the V2 adapters.

This is not a judgement on the change itself. Several of these are real gaps we still want fixed; the base just moved out from under them.

Once #2829 merges, please rebase onto main, port the change to the V2 equivalent, and reopen (or open a fresh PR). Ping me and I'll prioritise the review.

…list The conversation timeline showed a Waiting line on desktop but nothing on iOS, and the mobile thread list showed no status at all. Mobile now derives the same normalized post-settlement background roster the server and web derive, appends the matching row to the thread feed, and gives the classic list resolver the Waiting pill its web counterpart already has. The conversation view prefers deriveThreadRuntime(projection), so activeWorkStartedAt went null at settlement and the row it gated simply vanished. The row is now driven by the roster rather than by run timing. The list gap was the same shape as the classic web sidebar gap this PR fixes: the v2 list sits behind a preference that is off, so the list that renders is the classic one, whose resolveThreadStatus had no Waiting branch. It now ranks a static muted Waiting pill below approvals, input, active work and failures, and above Plan Ready. Teaching the v2 list resolver about Waiting is pingdotgg#4415 waiting-presentation's concern, not this commit's. The derivation lives in deriveThreadPendingBackgroundWork rather than inline in the composer hook so the policy is unit tested. It passes runs, which the web call site in ChatView also passes, so turn items owned by a rolled_back run are abandoned on mobile exactly as they are on desktop. Without that argument the shared helper sees an empty rolled-back set and iOS would show Waiting where desktop does not. Working and Waiting are chosen from the parked runtime rather than from run timing alone. A successful run persists as waiting with a null completedAt until checkpoint capture lands, so deriveActiveWorkStartedAt keeps reporting a start time for that whole window; deriveThreadWorkingStartedAt suppresses it once the roster has parked the runtime at idle, which is how web sequences the two. A waiting run with an empty roster still reads Working, since that is checkpoint capture with no background work behind it. Two defensive points. Mobile restores projections from disk and shouldPersistThread persists only settled ones, so a cached projection is exactly the shape that reproduces a Waiting row for work that already finished; the roster is therefore gated on a live thread detail, and synchronizing is refused alongside cached because a subscription passes through it before any fresh projection arrives. And formatPendingBackgroundWorkLabel interpolates the raw description, which for a subagent item is the whole child prompt, so the label is clamped to two lines. Co-authored-by: codex <codex@users.noreply.github.com>

Update sidebar and mobile expectations for the pingdotgg#4415 Waiting status, repair command-suite settle/interrupt coverage after layer merges, and remove a duplicate settledAt JSON field that broke contracts typecheck.

CTM's own subagent hiding (97a04be) skips delegated children inside buildThreadListV2Items, so the list is right, but hasAnyThreads still counts them. A user whose only live threads are subagent children therefore gets the in-list "No results" state instead of the full-page "No threads yet". Also corrects the threadListV2 header comment left by the CTM merge: pingdotgg#4415 sidebar-waiting-state describes Waiting as session.idle, while this line keys it off runtime.idle.

t3dotgg · 2026-07-24T01:12:04Z

When the agent stops while background tasks (subagents, background bash, monitors) are still running, the sidebar showed Done, then flicked back to Working when a task completion woke the agent (median 13s later, from local history).

Now ingestion tracks provider-reported open tasks per thread and parks the session on the previously-unused idle status when a turn ends with tasks still open. Sidebar v2 (web + mobile) renders it as a grey Waiting label with the same elapsed timer as Working; the row recedes like other in-flight states. Waiting flips directly to Working on wake-up — no intermediate Done.

Task set is keyed by provider instance and cleared on exit/stop/error, so stale tasks can't park a fresh session.
idle was already handled as "resting" by settlement, projection, and phase logic, so no contract or migration changes; old clients degrade to today's behavior.
Codex/OpenCode don't emit task events — behavior unchanged there.

🤖 Generated with Claude Code

Note

Medium Risk
Changes core session lifecycle in ProviderRuntimeIngestion (when threads show ready vs idle), with broad integration tests but no contract migration—incorrect task tracking could mislabel thread state across clients.

Overview
Threads that finish a turn while provider background tasks (monitors, subagents, etc.) are still open no longer flash Done before the wake-up turn. Provider runtime ingestion now tracks open tasks per thread and provider instance and parks the session on idle instead of ready when a turn ends with tasks still open; task state is cleared on session exit, error, and stale-instance guards, with tombstones for late events.

Web sidebar v2 and the mobile thread list map idle to a muted Waiting label (same elapsed timer as Working, in-flight row treatment). Successful task completion is expected to wake the agent without an intermediate ready; only a stopped last task returns Waiting to ready.

^{Reviewed by Cursor Bugbot for commit 368e0e1. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Add 'waiting' status for threads with open background tasks

Introduces a new idle session status that signals a thread is waiting on background tasks (e.g. PR monitors) rather than active user input or processing.
ProviderRuntimeIngestion tracks open tasks per thread/provider instance and transitions sessions to idle at rest when tasks remain open, returning to ready when the last task completes.
The web sidebar and mobile thread list both render idle sessions as 'Waiting' with a neutral style and an elapsed duration, treated as in-flight for display purposes.
Open task state is cleared on session exit or error so future sessions do not inherit the waiting state.
Behavioral Change: threads that previously resolved to ready while background tasks were open will now show as waiting until those tasks complete.

^{Macroscope summarized 368e0e1.}

coderabbitai · 2026-07-24T01:12:12Z

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 91fb2c98-8548-4670-a2cd-2cbb6e8a3eee

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

Create PR with unit tests
Commit unit tests in branch t3code/sidebar-waiting-state

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

macroscopeapp · 2026-07-24T01:16:45Z

Approvability

Verdict: Needs human review

New feature introducing a 'waiting' status with non-trivial server-side state tracking logic for background tasks. While well-tested, new user-facing behavior and runtime session status changes warrant human review.

^{You can customize Macroscope's approvability policy. Learn more.}

When the agent stops with background tasks (subagents, background bash, monitors) still running, the thread showed Done, then flicked back to Working when a task completion woke the agent. Track provider-reported open tasks in ingestion and park the session on the previously-unused "idle" status; sidebar v2 renders it as a grey "Waiting" with the same elapsed timer as Working. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Review fixes: gate the terminal-status task sweep behind the lifecycle guard so rejected stale events cannot erase the active turn's tasks; ignore task starts from a provider instance that doesn't match the projected session instead of letting them displace the current set; tombstone completed task ids so late/duplicate progress cannot re-open a finished task and park the thread on Waiting. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

A completed/failed final task wakes the agent (its notification is the wake signal), so Waiting flips straight to Working. A stopped final task is a kill — no wake follows — and previously left a live session parked on Waiting until teardown. Flip that case back to ready, and tombstone completions that outrun their start event. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

cursor

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 514fccf. Configure here.}

Tombstones exist to stop late/duplicate progress from resurrecting a finished task, but providers reuse task ids when an agent is resumed — a fresh task.started after completion is real work, not a replay. Progress stays blocked by the tombstone; an explicit start clears it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Real-data feedback round two: - Results render as a responsive grid (1/2/3 columns) instead of a full-width list. - While the sweep runs, the page shows only a progress count ("Reviewing your work — 7 of 18"); results reveal all at once when every thread is done, so triage happens in one pass over a stable layout instead of chasing cards as they pop in. - The model now returns a one-sentence imperative nextStep ("Review and merge PR #4415.") which becomes the card body — a direct answer to "what should I do here". Summaries are capped at one sentence and demoted to an info-icon tooltip. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…2.1-next Absorb CTM tip 408efa6 (Claude replay cleanup, ACP auth/fork provenance, derived-thread wake, fork-shell navigation wait) onto the pingdotgg#4415 Waiting sequence pinned at main ece0508. Conflict resolution (same intent as prior merge 616da6976): - Sidebar/threadList Waiting uses runtime.idle (CTM/orchestrator-v2 park) rather than session.idle from main pingdotgg#4415, including mobile tests. - Drop ProviderRuntimeIngestion (deleted on CTM; v2 uses orchestration-v2).

Update sidebar and mobile expectations for the pingdotgg#4415 Waiting status, repair command-suite settle/interrupt coverage after layer merges, and remove a duplicate settledAt JSON field that broke contracts typecheck.

…list The conversation timeline showed a Waiting line on desktop but nothing on iOS, and the mobile thread list showed no status at all. Mobile now derives the same normalized post-settlement background roster the server and web derive, appends the matching row to the thread feed, and gives the classic list resolver the Waiting pill its web counterpart already has. The conversation view prefers deriveThreadRuntime(projection), so activeWorkStartedAt went null at settlement and the row it gated simply vanished. The row is now driven by the roster rather than by run timing. The list gap was the same shape as the classic web sidebar gap this PR fixes: the v2 list sits behind a preference that is off, so the list that renders is the classic one, whose resolveThreadStatus had no Waiting branch. It now ranks a static muted Waiting pill below approvals, input, active work and failures, and above Plan Ready. Teaching the v2 list resolver about Waiting is pingdotgg#4415 waiting-presentation's concern, not this commit's. The derivation lives in deriveThreadPendingBackgroundWork rather than inline in the composer hook so the policy is unit tested. It passes runs, which the web call site in ChatView also passes, so turn items owned by a rolled_back run are abandoned on mobile exactly as they are on desktop. Without that argument the shared helper sees an empty rolled-back set and iOS would show Waiting where desktop does not. Working and Waiting are chosen from the parked runtime rather than from run timing alone. A successful run persists as waiting with a null completedAt until checkpoint capture lands, so deriveActiveWorkStartedAt keeps reporting a start time for that whole window; deriveThreadWorkingStartedAt suppresses it once the roster has parked the runtime at idle, which is how web sequences the two. A waiting run with an empty roster still reads Working, since that is checkpoint capture with no background work behind it. Two defensive points. Mobile restores projections from disk and shouldPersistThread persists only settled ones, so a cached projection is exactly the shape that reproduces a Waiting row for work that already finished; the roster is therefore gated on a live thread detail, and synchronizing is refused alongside cached because a subscription passes through it before any fresh projection arrives. And formatPendingBackgroundWorkLabel interpolates the raw description, which for a subagent item is the whole child prompt, so the label is clamped to two lines. Co-authored-by: codex <codex@users.noreply.github.com>

Update sidebar and mobile expectations for the pingdotgg#4415 Waiting status, repair command-suite settle/interrupt coverage after layer merges, and remove a duplicate settledAt JSON field that broke contracts typecheck.

juliusmarminge · 2026-07-30T15:37:00Z

Closing in favor of #2829 (orchestration V2).

#2829 deletes the V1 orchestration layer this PR builds on — apps/server/src/orchestration/**, provider/Layers/*Adapter.ts and provider/Services/** are removed and replaced by apps/server/src/orchestration-v2/**, with the IPC surface renamed to ORCHESTRATION_V2_WS_METHODS. The files this PR touches either no longer exist or are rewritten, so it can't be rebased — it would need reimplementing against the V2 adapters.

This is not a judgement on the change itself. Several of these are real gaps we still want fixed; the base just moved out from under them.

Once #2829 merges, please rebase onto main, port the change to the V2 equivalent, and reopen (or open a fresh PR). Ping me and I'll prioritise the review.

…list The conversation timeline showed a Waiting line on desktop but nothing on iOS, and the mobile thread list showed no status at all. Mobile now derives the same normalized post-settlement background roster the server and web derive, appends the matching row to the thread feed, and gives the classic list resolver the Waiting pill its web counterpart already has. The conversation view prefers deriveThreadRuntime(projection), so activeWorkStartedAt went null at settlement and the row it gated simply vanished. The row is now driven by the roster rather than by run timing. The list gap was the same shape as the classic web sidebar gap this PR fixes: the v2 list sits behind a preference that is off, so the list that renders is the classic one, whose resolveThreadStatus had no Waiting branch. It now ranks a static muted Waiting pill below approvals, input, active work and failures, and above Plan Ready. Teaching the v2 list resolver about Waiting is pingdotgg#4415 waiting-presentation's concern, not this commit's. The derivation lives in deriveThreadPendingBackgroundWork rather than inline in the composer hook so the policy is unit tested. It passes runs, which the web call site in ChatView also passes, so turn items owned by a rolled_back run are abandoned on mobile exactly as they are on desktop. Without that argument the shared helper sees an empty rolled-back set and iOS would show Waiting where desktop does not. Working and Waiting are chosen from the parked runtime rather than from run timing alone. A successful run persists as waiting with a null completedAt until checkpoint capture lands, so deriveActiveWorkStartedAt keeps reporting a start time for that whole window; deriveThreadWorkingStartedAt suppresses it once the roster has parked the runtime at idle, which is how web sequences the two. A waiting run with an empty roster still reads Working, since that is checkpoint capture with no background work behind it. Two defensive points. Mobile restores projections from disk and shouldPersistThread persists only settled ones, so a cached projection is exactly the shape that reproduces a Waiting row for work that already finished; the roster is therefore gated on a live thread detail, and synchronizing is refused alongside cached because a subscription passes through it before any fresh projection arrives. And formatPendingBackgroundWorkLabel interpolates the raw description, which for a subagent item is the whole child prompt, so the label is clamped to two lines. Co-authored-by: codex <codex@users.noreply.github.com>

Update sidebar and mobile expectations for the pingdotgg#4415 Waiting status, repair command-suite settle/interrupt coverage after layer merges, and remove a duplicate settledAt JSON field that broke contracts typecheck.

CTM's own subagent hiding (97a04be) skips delegated children inside buildThreadListV2Items, so the list is right, but hasAnyThreads still counts them. A user whose only live threads are subagent children therefore gets the in-list "No results" state instead of the full-page "No threads yet". Also corrects the threadListV2 header comment left by the CTM merge: pingdotgg#4415 sidebar-waiting-state describes Waiting as session.idle, while this line keys it off runtime.idle.

t3dotgg · 2026-07-24T01:12:04Z

When the agent stops while background tasks (subagents, background bash, monitors) are still running, the sidebar showed Done, then flicked back to Working when a task completion woke the agent (median 13s later, from local history).

Now ingestion tracks provider-reported open tasks per thread and parks the session on the previously-unused idle status when a turn ends with tasks still open. Sidebar v2 (web + mobile) renders it as a grey Waiting label with the same elapsed timer as Working; the row recedes like other in-flight states. Waiting flips directly to Working on wake-up — no intermediate Done.

Task set is keyed by provider instance and cleared on exit/stop/error, so stale tasks can't park a fresh session.
idle was already handled as "resting" by settlement, projection, and phase logic, so no contract or migration changes; old clients degrade to today's behavior.
Codex/OpenCode don't emit task events — behavior unchanged there.

🤖 Generated with Claude Code

Note

Medium Risk
Changes core session lifecycle in ProviderRuntimeIngestion (when threads show ready vs idle), with broad integration tests but no contract migration—incorrect task tracking could mislabel thread state across clients.

Overview
Threads that finish a turn while provider background tasks (monitors, subagents, etc.) are still open no longer flash Done before the wake-up turn. Provider runtime ingestion now tracks open tasks per thread and provider instance and parks the session on idle instead of ready when a turn ends with tasks still open; task state is cleared on session exit, error, and stale-instance guards, with tombstones for late events.

Web sidebar v2 and the mobile thread list map idle to a muted Waiting label (same elapsed timer as Working, in-flight row treatment). Successful task completion is expected to wake the agent without an intermediate ready; only a stopped last task returns Waiting to ready.

^{Reviewed by Cursor Bugbot for commit 368e0e1. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Add 'waiting' status for threads with open background tasks

Introduces a new idle session status that signals a thread is waiting on background tasks (e.g. PR monitors) rather than active user input or processing.
ProviderRuntimeIngestion tracks open tasks per thread/provider instance and transitions sessions to idle at rest when tasks remain open, returning to ready when the last task completes.
The web sidebar and mobile thread list both render idle sessions as 'Waiting' with a neutral style and an elapsed duration, treated as in-flight for display purposes.
Open task state is cleared on session exit or error so future sessions do not inherit the waiting state.
Behavioral Change: threads that previously resolved to ready while background tasks were open will now show as waiting until those tasks complete.

^{Macroscope summarized 368e0e1.}

coderabbitai · 2026-07-24T01:12:12Z

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 91fb2c98-8548-4670-a2cd-2cbb6e8a3eee

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

Create PR with unit tests
Commit unit tests in branch t3code/sidebar-waiting-state

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

macroscopeapp · 2026-07-24T01:16:45Z

Approvability

Verdict: Needs human review

New feature introducing a 'waiting' status with non-trivial server-side state tracking logic for background tasks. While well-tested, new user-facing behavior and runtime session status changes warrant human review.

^{You can customize Macroscope's approvability policy. Learn more.}

When the agent stops with background tasks (subagents, background bash, monitors) still running, the thread showed Done, then flicked back to Working when a task completion woke the agent. Track provider-reported open tasks in ingestion and park the session on the previously-unused "idle" status; sidebar v2 renders it as a grey "Waiting" with the same elapsed timer as Working. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Review fixes: gate the terminal-status task sweep behind the lifecycle guard so rejected stale events cannot erase the active turn's tasks; ignore task starts from a provider instance that doesn't match the projected session instead of letting them displace the current set; tombstone completed task ids so late/duplicate progress cannot re-open a finished task and park the thread on Waiting. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

A completed/failed final task wakes the agent (its notification is the wake signal), so Waiting flips straight to Working. A stopped final task is a kill — no wake follows — and previously left a live session parked on Waiting until teardown. Flip that case back to ready, and tombstone completions that outrun their start event. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

cursor

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 514fccf. Configure here.}

Tombstones exist to stop late/duplicate progress from resurrecting a finished task, but providers reuse task ids when an agent is resumed — a fresh task.started after completion is real work, not a replay. Progress stays blocked by the tombstone; an explicit start clears it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Real-data feedback round two: - Results render as a responsive grid (1/2/3 columns) instead of a full-width list. - While the sweep runs, the page shows only a progress count ("Reviewing your work — 7 of 18"); results reveal all at once when every thread is done, so triage happens in one pass over a stable layout instead of chasing cards as they pop in. - The model now returns a one-sentence imperative nextStep ("Review and merge PR #4415.") which becomes the card body — a direct answer to "what should I do here". Summaries are capped at one sentence and demoted to an info-icon tooltip. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…2.1-next Absorb CTM tip 408efa6 (Claude replay cleanup, ACP auth/fork provenance, derived-thread wake, fork-shell navigation wait) onto the pingdotgg#4415 Waiting sequence pinned at main ece0508. Conflict resolution (same intent as prior merge 616da6976): - Sidebar/threadList Waiting uses runtime.idle (CTM/orchestrator-v2 park) rather than session.idle from main pingdotgg#4415, including mobile tests. - Drop ProviderRuntimeIngestion (deleted on CTM; v2 uses orchestration-v2).

Update sidebar and mobile expectations for the pingdotgg#4415 Waiting status, repair command-suite settle/interrupt coverage after layer merges, and remove a duplicate settledAt JSON field that broke contracts typecheck.

…list The conversation timeline showed a Waiting line on desktop but nothing on iOS, and the mobile thread list showed no status at all. Mobile now derives the same normalized post-settlement background roster the server and web derive, appends the matching row to the thread feed, and gives the classic list resolver the Waiting pill its web counterpart already has. The conversation view prefers deriveThreadRuntime(projection), so activeWorkStartedAt went null at settlement and the row it gated simply vanished. The row is now driven by the roster rather than by run timing. The list gap was the same shape as the classic web sidebar gap this PR fixes: the v2 list sits behind a preference that is off, so the list that renders is the classic one, whose resolveThreadStatus had no Waiting branch. It now ranks a static muted Waiting pill below approvals, input, active work and failures, and above Plan Ready. Teaching the v2 list resolver about Waiting is pingdotgg#4415 waiting-presentation's concern, not this commit's. The derivation lives in deriveThreadPendingBackgroundWork rather than inline in the composer hook so the policy is unit tested. It passes runs, which the web call site in ChatView also passes, so turn items owned by a rolled_back run are abandoned on mobile exactly as they are on desktop. Without that argument the shared helper sees an empty rolled-back set and iOS would show Waiting where desktop does not. Working and Waiting are chosen from the parked runtime rather than from run timing alone. A successful run persists as waiting with a null completedAt until checkpoint capture lands, so deriveActiveWorkStartedAt keeps reporting a start time for that whole window; deriveThreadWorkingStartedAt suppresses it once the roster has parked the runtime at idle, which is how web sequences the two. A waiting run with an empty roster still reads Working, since that is checkpoint capture with no background work behind it. Two defensive points. Mobile restores projections from disk and shouldPersistThread persists only settled ones, so a cached projection is exactly the shape that reproduces a Waiting row for work that already finished; the roster is therefore gated on a live thread detail, and synchronizing is refused alongside cached because a subscription passes through it before any fresh projection arrives. And formatPendingBackgroundWorkLabel interpolates the raw description, which for a subagent item is the whole child prompt, so the label is clamped to two lines. Co-authored-by: codex <codex@users.noreply.github.com>

Update sidebar and mobile expectations for the pingdotgg#4415 Waiting status, repair command-suite settle/interrupt coverage after layer merges, and remove a duplicate settledAt JSON field that broke contracts typecheck.

juliusmarminge · 2026-07-30T15:37:00Z

Closing in favor of #2829 (orchestration V2).

#2829 deletes the V1 orchestration layer this PR builds on — apps/server/src/orchestration/**, provider/Layers/*Adapter.ts and provider/Services/** are removed and replaced by apps/server/src/orchestration-v2/**, with the IPC surface renamed to ORCHESTRATION_V2_WS_METHODS. The files this PR touches either no longer exist or are rewritten, so it can't be rebased — it would need reimplementing against the V2 adapters.

This is not a judgement on the change itself. Several of these are real gaps we still want fixed; the base just moved out from under them.

Once #2829 merges, please rebase onto main, port the change to the V2 equivalent, and reopen (or open a fresh PR). Ping me and I'll prioritise the review.

…list The conversation timeline showed a Waiting line on desktop but nothing on iOS, and the mobile thread list showed no status at all. Mobile now derives the same normalized post-settlement background roster the server and web derive, appends the matching row to the thread feed, and gives the classic list resolver the Waiting pill its web counterpart already has. The conversation view prefers deriveThreadRuntime(projection), so activeWorkStartedAt went null at settlement and the row it gated simply vanished. The row is now driven by the roster rather than by run timing. The list gap was the same shape as the classic web sidebar gap this PR fixes: the v2 list sits behind a preference that is off, so the list that renders is the classic one, whose resolveThreadStatus had no Waiting branch. It now ranks a static muted Waiting pill below approvals, input, active work and failures, and above Plan Ready. Teaching the v2 list resolver about Waiting is pingdotgg#4415 waiting-presentation's concern, not this commit's. The derivation lives in deriveThreadPendingBackgroundWork rather than inline in the composer hook so the policy is unit tested. It passes runs, which the web call site in ChatView also passes, so turn items owned by a rolled_back run are abandoned on mobile exactly as they are on desktop. Without that argument the shared helper sees an empty rolled-back set and iOS would show Waiting where desktop does not. Working and Waiting are chosen from the parked runtime rather than from run timing alone. A successful run persists as waiting with a null completedAt until checkpoint capture lands, so deriveActiveWorkStartedAt keeps reporting a start time for that whole window; deriveThreadWorkingStartedAt suppresses it once the roster has parked the runtime at idle, which is how web sequences the two. A waiting run with an empty roster still reads Working, since that is checkpoint capture with no background work behind it. Two defensive points. Mobile restores projections from disk and shouldPersistThread persists only settled ones, so a cached projection is exactly the shape that reproduces a Waiting row for work that already finished; the roster is therefore gated on a live thread detail, and synchronizing is refused alongside cached because a subscription passes through it before any fresh projection arrives. And formatPendingBackgroundWorkLabel interpolates the raw description, which for a subagent item is the whole child prompt, so the label is clamped to two lines. Co-authored-by: codex <codex@users.noreply.github.com>

Update sidebar and mobile expectations for the pingdotgg#4415 Waiting status, repair command-suite settle/interrupt coverage after layer merges, and remove a duplicate settledAt JSON field that broke contracts typecheck.

CTM's own subagent hiding (97a04be) skips delegated children inside buildThreadListV2Items, so the list is right, but hasAnyThreads still counts them. A user whose only live threads are subagent children therefore gets the in-list "No results" state instead of the full-page "No threads yet". Also corrects the threadListV2 header comment left by the CTM merge: pingdotgg#4415 sidebar-waiting-state describes Waiting as session.idle, while this line keys it off runtime.idle.

t3dotgg · 2026-07-24T01:12:04Z

When the agent stops while background tasks (subagents, background bash, monitors) are still running, the sidebar showed Done, then flicked back to Working when a task completion woke the agent (median 13s later, from local history).

Now ingestion tracks provider-reported open tasks per thread and parks the session on the previously-unused idle status when a turn ends with tasks still open. Sidebar v2 (web + mobile) renders it as a grey Waiting label with the same elapsed timer as Working; the row recedes like other in-flight states. Waiting flips directly to Working on wake-up — no intermediate Done.

Task set is keyed by provider instance and cleared on exit/stop/error, so stale tasks can't park a fresh session.
idle was already handled as "resting" by settlement, projection, and phase logic, so no contract or migration changes; old clients degrade to today's behavior.
Codex/OpenCode don't emit task events — behavior unchanged there.

🤖 Generated with Claude Code

Note

Medium Risk
Changes core session lifecycle in ProviderRuntimeIngestion (when threads show ready vs idle), with broad integration tests but no contract migration—incorrect task tracking could mislabel thread state across clients.

Overview
Threads that finish a turn while provider background tasks (monitors, subagents, etc.) are still open no longer flash Done before the wake-up turn. Provider runtime ingestion now tracks open tasks per thread and provider instance and parks the session on idle instead of ready when a turn ends with tasks still open; task state is cleared on session exit, error, and stale-instance guards, with tombstones for late events.

Web sidebar v2 and the mobile thread list map idle to a muted Waiting label (same elapsed timer as Working, in-flight row treatment). Successful task completion is expected to wake the agent without an intermediate ready; only a stopped last task returns Waiting to ready.

^{Reviewed by Cursor Bugbot for commit 368e0e1. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Add 'waiting' status for threads with open background tasks

Introduces a new idle session status that signals a thread is waiting on background tasks (e.g. PR monitors) rather than active user input or processing.
ProviderRuntimeIngestion tracks open tasks per thread/provider instance and transitions sessions to idle at rest when tasks remain open, returning to ready when the last task completes.
The web sidebar and mobile thread list both render idle sessions as 'Waiting' with a neutral style and an elapsed duration, treated as in-flight for display purposes.
Open task state is cleared on session exit or error so future sessions do not inherit the waiting state.
Behavioral Change: threads that previously resolved to ready while background tasks were open will now show as waiting until those tasks complete.

^{Macroscope summarized 368e0e1.}

coderabbitai · 2026-07-24T01:12:12Z

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 91fb2c98-8548-4670-a2cd-2cbb6e8a3eee

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

Create PR with unit tests
Commit unit tests in branch t3code/sidebar-waiting-state

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

macroscopeapp · 2026-07-24T01:16:45Z

Approvability

Verdict: Needs human review

New feature introducing a 'waiting' status with non-trivial server-side state tracking logic for background tasks. While well-tested, new user-facing behavior and runtime session status changes warrant human review.

^{You can customize Macroscope's approvability policy. Learn more.}

When the agent stops with background tasks (subagents, background bash, monitors) still running, the thread showed Done, then flicked back to Working when a task completion woke the agent. Track provider-reported open tasks in ingestion and park the session on the previously-unused "idle" status; sidebar v2 renders it as a grey "Waiting" with the same elapsed timer as Working. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Review fixes: gate the terminal-status task sweep behind the lifecycle guard so rejected stale events cannot erase the active turn's tasks; ignore task starts from a provider instance that doesn't match the projected session instead of letting them displace the current set; tombstone completed task ids so late/duplicate progress cannot re-open a finished task and park the thread on Waiting. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

A completed/failed final task wakes the agent (its notification is the wake signal), so Waiting flips straight to Working. A stopped final task is a kill — no wake follows — and previously left a live session parked on Waiting until teardown. Flip that case back to ready, and tombstone completions that outrun their start event. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

cursor

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 514fccf. Configure here.}

Tombstones exist to stop late/duplicate progress from resurrecting a finished task, but providers reuse task ids when an agent is resumed — a fresh task.started after completion is real work, not a replay. Progress stays blocked by the tombstone; an explicit start clears it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Real-data feedback round two: - Results render as a responsive grid (1/2/3 columns) instead of a full-width list. - While the sweep runs, the page shows only a progress count ("Reviewing your work — 7 of 18"); results reveal all at once when every thread is done, so triage happens in one pass over a stable layout instead of chasing cards as they pop in. - The model now returns a one-sentence imperative nextStep ("Review and merge PR #4415.") which becomes the card body — a direct answer to "what should I do here". Summaries are capped at one sentence and demoted to an info-icon tooltip. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…2.1-next Absorb CTM tip 408efa6 (Claude replay cleanup, ACP auth/fork provenance, derived-thread wake, fork-shell navigation wait) onto the pingdotgg#4415 Waiting sequence pinned at main ece0508. Conflict resolution (same intent as prior merge 616da6976): - Sidebar/threadList Waiting uses runtime.idle (CTM/orchestrator-v2 park) rather than session.idle from main pingdotgg#4415, including mobile tests. - Drop ProviderRuntimeIngestion (deleted on CTM; v2 uses orchestration-v2).

Update sidebar and mobile expectations for the pingdotgg#4415 Waiting status, repair command-suite settle/interrupt coverage after layer merges, and remove a duplicate settledAt JSON field that broke contracts typecheck.

…list The conversation timeline showed a Waiting line on desktop but nothing on iOS, and the mobile thread list showed no status at all. Mobile now derives the same normalized post-settlement background roster the server and web derive, appends the matching row to the thread feed, and gives the classic list resolver the Waiting pill its web counterpart already has. The conversation view prefers deriveThreadRuntime(projection), so activeWorkStartedAt went null at settlement and the row it gated simply vanished. The row is now driven by the roster rather than by run timing. The list gap was the same shape as the classic web sidebar gap this PR fixes: the v2 list sits behind a preference that is off, so the list that renders is the classic one, whose resolveThreadStatus had no Waiting branch. It now ranks a static muted Waiting pill below approvals, input, active work and failures, and above Plan Ready. Teaching the v2 list resolver about Waiting is pingdotgg#4415 waiting-presentation's concern, not this commit's. The derivation lives in deriveThreadPendingBackgroundWork rather than inline in the composer hook so the policy is unit tested. It passes runs, which the web call site in ChatView also passes, so turn items owned by a rolled_back run are abandoned on mobile exactly as they are on desktop. Without that argument the shared helper sees an empty rolled-back set and iOS would show Waiting where desktop does not. Working and Waiting are chosen from the parked runtime rather than from run timing alone. A successful run persists as waiting with a null completedAt until checkpoint capture lands, so deriveActiveWorkStartedAt keeps reporting a start time for that whole window; deriveThreadWorkingStartedAt suppresses it once the roster has parked the runtime at idle, which is how web sequences the two. A waiting run with an empty roster still reads Working, since that is checkpoint capture with no background work behind it. Two defensive points. Mobile restores projections from disk and shouldPersistThread persists only settled ones, so a cached projection is exactly the shape that reproduces a Waiting row for work that already finished; the roster is therefore gated on a live thread detail, and synchronizing is refused alongside cached because a subscription passes through it before any fresh projection arrives. And formatPendingBackgroundWorkLabel interpolates the raw description, which for a subagent item is the whole child prompt, so the label is clamped to two lines. Co-authored-by: codex <codex@users.noreply.github.com>

Update sidebar and mobile expectations for the pingdotgg#4415 Waiting status, repair command-suite settle/interrupt coverage after layer merges, and remove a duplicate settledAt JSON field that broke contracts typecheck.

juliusmarminge · 2026-07-30T15:37:00Z

Closing in favor of #2829 (orchestration V2).

#2829 deletes the V1 orchestration layer this PR builds on — apps/server/src/orchestration/**, provider/Layers/*Adapter.ts and provider/Services/** are removed and replaced by apps/server/src/orchestration-v2/**, with the IPC surface renamed to ORCHESTRATION_V2_WS_METHODS. The files this PR touches either no longer exist or are rewritten, so it can't be rebased — it would need reimplementing against the V2 adapters.

This is not a judgement on the change itself. Several of these are real gaps we still want fixed; the base just moved out from under them.

Once #2829 merges, please rebase onto main, port the change to the V2 equivalent, and reopen (or open a fresh PR). Ping me and I'll prioritise the review.

…list The conversation timeline showed a Waiting line on desktop but nothing on iOS, and the mobile thread list showed no status at all. Mobile now derives the same normalized post-settlement background roster the server and web derive, appends the matching row to the thread feed, and gives the classic list resolver the Waiting pill its web counterpart already has. The conversation view prefers deriveThreadRuntime(projection), so activeWorkStartedAt went null at settlement and the row it gated simply vanished. The row is now driven by the roster rather than by run timing. The list gap was the same shape as the classic web sidebar gap this PR fixes: the v2 list sits behind a preference that is off, so the list that renders is the classic one, whose resolveThreadStatus had no Waiting branch. It now ranks a static muted Waiting pill below approvals, input, active work and failures, and above Plan Ready. Teaching the v2 list resolver about Waiting is pingdotgg#4415 waiting-presentation's concern, not this commit's. The derivation lives in deriveThreadPendingBackgroundWork rather than inline in the composer hook so the policy is unit tested. It passes runs, which the web call site in ChatView also passes, so turn items owned by a rolled_back run are abandoned on mobile exactly as they are on desktop. Without that argument the shared helper sees an empty rolled-back set and iOS would show Waiting where desktop does not. Working and Waiting are chosen from the parked runtime rather than from run timing alone. A successful run persists as waiting with a null completedAt until checkpoint capture lands, so deriveActiveWorkStartedAt keeps reporting a start time for that whole window; deriveThreadWorkingStartedAt suppresses it once the roster has parked the runtime at idle, which is how web sequences the two. A waiting run with an empty roster still reads Working, since that is checkpoint capture with no background work behind it. Two defensive points. Mobile restores projections from disk and shouldPersistThread persists only settled ones, so a cached projection is exactly the shape that reproduces a Waiting row for work that already finished; the roster is therefore gated on a live thread detail, and synchronizing is refused alongside cached because a subscription passes through it before any fresh projection arrives. And formatPendingBackgroundWorkLabel interpolates the raw description, which for a subagent item is the whole child prompt, so the label is clamped to two lines. Co-authored-by: codex <codex@users.noreply.github.com>

Update sidebar and mobile expectations for the pingdotgg#4415 Waiting status, repair command-suite settle/interrupt coverage after layer merges, and remove a duplicate settledAt JSON field that broke contracts typecheck.

CTM's own subagent hiding (97a04be) skips delegated children inside buildThreadListV2Items, so the list is right, but hasAnyThreads still counts them. A user whose only live threads are subagent children therefore gets the in-list "No results" state instead of the full-page "No threads yet". Also corrects the threadListV2 header comment left by the CTM merge: pingdotgg#4415 sidebar-waiting-state describes Waiting as session.idle, while this line keys it off runtime.idle.

t3dotgg · 2026-07-24T01:12:04Z

When the agent stops while background tasks (subagents, background bash, monitors) are still running, the sidebar showed Done, then flicked back to Working when a task completion woke the agent (median 13s later, from local history).

Now ingestion tracks provider-reported open tasks per thread and parks the session on the previously-unused idle status when a turn ends with tasks still open. Sidebar v2 (web + mobile) renders it as a grey Waiting label with the same elapsed timer as Working; the row recedes like other in-flight states. Waiting flips directly to Working on wake-up — no intermediate Done.

Task set is keyed by provider instance and cleared on exit/stop/error, so stale tasks can't park a fresh session.
idle was already handled as "resting" by settlement, projection, and phase logic, so no contract or migration changes; old clients degrade to today's behavior.
Codex/OpenCode don't emit task events — behavior unchanged there.

🤖 Generated with Claude Code

Note

Medium Risk
Changes core session lifecycle in ProviderRuntimeIngestion (when threads show ready vs idle), with broad integration tests but no contract migration—incorrect task tracking could mislabel thread state across clients.

Overview
Threads that finish a turn while provider background tasks (monitors, subagents, etc.) are still open no longer flash Done before the wake-up turn. Provider runtime ingestion now tracks open tasks per thread and provider instance and parks the session on idle instead of ready when a turn ends with tasks still open; task state is cleared on session exit, error, and stale-instance guards, with tombstones for late events.

Web sidebar v2 and the mobile thread list map idle to a muted Waiting label (same elapsed timer as Working, in-flight row treatment). Successful task completion is expected to wake the agent without an intermediate ready; only a stopped last task returns Waiting to ready.

^{Reviewed by Cursor Bugbot for commit 368e0e1. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Add 'waiting' status for threads with open background tasks

Introduces a new idle session status that signals a thread is waiting on background tasks (e.g. PR monitors) rather than active user input or processing.
ProviderRuntimeIngestion tracks open tasks per thread/provider instance and transitions sessions to idle at rest when tasks remain open, returning to ready when the last task completes.
The web sidebar and mobile thread list both render idle sessions as 'Waiting' with a neutral style and an elapsed duration, treated as in-flight for display purposes.
Open task state is cleared on session exit or error so future sessions do not inherit the waiting state.
Behavioral Change: threads that previously resolved to ready while background tasks were open will now show as waiting until those tasks complete.

^{Macroscope summarized 368e0e1.}

coderabbitai · 2026-07-24T01:12:12Z

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 91fb2c98-8548-4670-a2cd-2cbb6e8a3eee

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

Create PR with unit tests
Commit unit tests in branch t3code/sidebar-waiting-state

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

macroscopeapp · 2026-07-24T01:16:45Z

Approvability

Verdict: Needs human review

New feature introducing a 'waiting' status with non-trivial server-side state tracking logic for background tasks. While well-tested, new user-facing behavior and runtime session status changes warrant human review.

^{You can customize Macroscope's approvability policy. Learn more.}

When the agent stops with background tasks (subagents, background bash, monitors) still running, the thread showed Done, then flicked back to Working when a task completion woke the agent. Track provider-reported open tasks in ingestion and park the session on the previously-unused "idle" status; sidebar v2 renders it as a grey "Waiting" with the same elapsed timer as Working. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Review fixes: gate the terminal-status task sweep behind the lifecycle guard so rejected stale events cannot erase the active turn's tasks; ignore task starts from a provider instance that doesn't match the projected session instead of letting them displace the current set; tombstone completed task ids so late/duplicate progress cannot re-open a finished task and park the thread on Waiting. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

A completed/failed final task wakes the agent (its notification is the wake signal), so Waiting flips straight to Working. A stopped final task is a kill — no wake follows — and previously left a live session parked on Waiting until teardown. Flip that case back to ready, and tombstone completions that outrun their start event. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

cursor

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 514fccf. Configure here.}

Tombstones exist to stop late/duplicate progress from resurrecting a finished task, but providers reuse task ids when an agent is resumed — a fresh task.started after completion is real work, not a replay. Progress stays blocked by the tombstone; an explicit start clears it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Real-data feedback round two: - Results render as a responsive grid (1/2/3 columns) instead of a full-width list. - While the sweep runs, the page shows only a progress count ("Reviewing your work — 7 of 18"); results reveal all at once when every thread is done, so triage happens in one pass over a stable layout instead of chasing cards as they pop in. - The model now returns a one-sentence imperative nextStep ("Review and merge PR #4415.") which becomes the card body — a direct answer to "what should I do here". Summaries are capped at one sentence and demoted to an info-icon tooltip. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…2.1-next Absorb CTM tip 408efa6 (Claude replay cleanup, ACP auth/fork provenance, derived-thread wake, fork-shell navigation wait) onto the pingdotgg#4415 Waiting sequence pinned at main ece0508. Conflict resolution (same intent as prior merge 616da6976): - Sidebar/threadList Waiting uses runtime.idle (CTM/orchestrator-v2 park) rather than session.idle from main pingdotgg#4415, including mobile tests. - Drop ProviderRuntimeIngestion (deleted on CTM; v2 uses orchestration-v2).

Update sidebar and mobile expectations for the pingdotgg#4415 Waiting status, repair command-suite settle/interrupt coverage after layer merges, and remove a duplicate settledAt JSON field that broke contracts typecheck.

…list The conversation timeline showed a Waiting line on desktop but nothing on iOS, and the mobile thread list showed no status at all. Mobile now derives the same normalized post-settlement background roster the server and web derive, appends the matching row to the thread feed, and gives the classic list resolver the Waiting pill its web counterpart already has. The conversation view prefers deriveThreadRuntime(projection), so activeWorkStartedAt went null at settlement and the row it gated simply vanished. The row is now driven by the roster rather than by run timing. The list gap was the same shape as the classic web sidebar gap this PR fixes: the v2 list sits behind a preference that is off, so the list that renders is the classic one, whose resolveThreadStatus had no Waiting branch. It now ranks a static muted Waiting pill below approvals, input, active work and failures, and above Plan Ready. Teaching the v2 list resolver about Waiting is pingdotgg#4415 waiting-presentation's concern, not this commit's. The derivation lives in deriveThreadPendingBackgroundWork rather than inline in the composer hook so the policy is unit tested. It passes runs, which the web call site in ChatView also passes, so turn items owned by a rolled_back run are abandoned on mobile exactly as they are on desktop. Without that argument the shared helper sees an empty rolled-back set and iOS would show Waiting where desktop does not. Working and Waiting are chosen from the parked runtime rather than from run timing alone. A successful run persists as waiting with a null completedAt until checkpoint capture lands, so deriveActiveWorkStartedAt keeps reporting a start time for that whole window; deriveThreadWorkingStartedAt suppresses it once the roster has parked the runtime at idle, which is how web sequences the two. A waiting run with an empty roster still reads Working, since that is checkpoint capture with no background work behind it. Two defensive points. Mobile restores projections from disk and shouldPersistThread persists only settled ones, so a cached projection is exactly the shape that reproduces a Waiting row for work that already finished; the roster is therefore gated on a live thread detail, and synchronizing is refused alongside cached because a subscription passes through it before any fresh projection arrives. And formatPendingBackgroundWorkLabel interpolates the raw description, which for a subagent item is the whole child prompt, so the label is clamped to two lines. Co-authored-by: codex <codex@users.noreply.github.com>

Update sidebar and mobile expectations for the pingdotgg#4415 Waiting status, repair command-suite settle/interrupt coverage after layer merges, and remove a duplicate settledAt JSON field that broke contracts typecheck.

juliusmarminge · 2026-07-30T15:37:00Z

Closing in favor of #2829 (orchestration V2).

#2829 deletes the V1 orchestration layer this PR builds on — apps/server/src/orchestration/**, provider/Layers/*Adapter.ts and provider/Services/** are removed and replaced by apps/server/src/orchestration-v2/**, with the IPC surface renamed to ORCHESTRATION_V2_WS_METHODS. The files this PR touches either no longer exist or are rewritten, so it can't be rebased — it would need reimplementing against the V2 adapters.

This is not a judgement on the change itself. Several of these are real gaps we still want fixed; the base just moved out from under them.

Once #2829 merges, please rebase onto main, port the change to the V2 equivalent, and reopen (or open a fresh PR). Ping me and I'll prioritise the review.

…list The conversation timeline showed a Waiting line on desktop but nothing on iOS, and the mobile thread list showed no status at all. Mobile now derives the same normalized post-settlement background roster the server and web derive, appends the matching row to the thread feed, and gives the classic list resolver the Waiting pill its web counterpart already has. The conversation view prefers deriveThreadRuntime(projection), so activeWorkStartedAt went null at settlement and the row it gated simply vanished. The row is now driven by the roster rather than by run timing. The list gap was the same shape as the classic web sidebar gap this PR fixes: the v2 list sits behind a preference that is off, so the list that renders is the classic one, whose resolveThreadStatus had no Waiting branch. It now ranks a static muted Waiting pill below approvals, input, active work and failures, and above Plan Ready. Teaching the v2 list resolver about Waiting is pingdotgg#4415 waiting-presentation's concern, not this commit's. The derivation lives in deriveThreadPendingBackgroundWork rather than inline in the composer hook so the policy is unit tested. It passes runs, which the web call site in ChatView also passes, so turn items owned by a rolled_back run are abandoned on mobile exactly as they are on desktop. Without that argument the shared helper sees an empty rolled-back set and iOS would show Waiting where desktop does not. Working and Waiting are chosen from the parked runtime rather than from run timing alone. A successful run persists as waiting with a null completedAt until checkpoint capture lands, so deriveActiveWorkStartedAt keeps reporting a start time for that whole window; deriveThreadWorkingStartedAt suppresses it once the roster has parked the runtime at idle, which is how web sequences the two. A waiting run with an empty roster still reads Working, since that is checkpoint capture with no background work behind it. Two defensive points. Mobile restores projections from disk and shouldPersistThread persists only settled ones, so a cached projection is exactly the shape that reproduces a Waiting row for work that already finished; the roster is therefore gated on a live thread detail, and synchronizing is refused alongside cached because a subscription passes through it before any fresh projection arrives. And formatPendingBackgroundWorkLabel interpolates the raw description, which for a subagent item is the whole child prompt, so the label is clamped to two lines. Co-authored-by: codex <codex@users.noreply.github.com>

Update sidebar and mobile expectations for the pingdotgg#4415 Waiting status, repair command-suite settle/interrupt coverage after layer merges, and remove a duplicate settledAt JSON field that broke contracts typecheck.

CTM's own subagent hiding (97a04be) skips delegated children inside buildThreadListV2Items, so the list is right, but hasAnyThreads still counts them. A user whose only live threads are subagent children therefore gets the in-list "No results" state instead of the full-page "No threads yet". Also corrects the threadListV2 header comment left by the CTM merge: pingdotgg#4415 sidebar-waiting-state describes Waiting as session.idle, while this line keys it off runtime.idle.

t3dotgg · 2026-07-24T01:12:04Z

When the agent stops while background tasks (subagents, background bash, monitors) are still running, the sidebar showed Done, then flicked back to Working when a task completion woke the agent (median 13s later, from local history).

Now ingestion tracks provider-reported open tasks per thread and parks the session on the previously-unused idle status when a turn ends with tasks still open. Sidebar v2 (web + mobile) renders it as a grey Waiting label with the same elapsed timer as Working; the row recedes like other in-flight states. Waiting flips directly to Working on wake-up — no intermediate Done.

Task set is keyed by provider instance and cleared on exit/stop/error, so stale tasks can't park a fresh session.
idle was already handled as "resting" by settlement, projection, and phase logic, so no contract or migration changes; old clients degrade to today's behavior.
Codex/OpenCode don't emit task events — behavior unchanged there.

🤖 Generated with Claude Code

Note

Medium Risk
Changes core session lifecycle in ProviderRuntimeIngestion (when threads show ready vs idle), with broad integration tests but no contract migration—incorrect task tracking could mislabel thread state across clients.

Overview
Threads that finish a turn while provider background tasks (monitors, subagents, etc.) are still open no longer flash Done before the wake-up turn. Provider runtime ingestion now tracks open tasks per thread and provider instance and parks the session on idle instead of ready when a turn ends with tasks still open; task state is cleared on session exit, error, and stale-instance guards, with tombstones for late events.

Web sidebar v2 and the mobile thread list map idle to a muted Waiting label (same elapsed timer as Working, in-flight row treatment). Successful task completion is expected to wake the agent without an intermediate ready; only a stopped last task returns Waiting to ready.

^{Reviewed by Cursor Bugbot for commit 368e0e1. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Add 'waiting' status for threads with open background tasks

Introduces a new idle session status that signals a thread is waiting on background tasks (e.g. PR monitors) rather than active user input or processing.
ProviderRuntimeIngestion tracks open tasks per thread/provider instance and transitions sessions to idle at rest when tasks remain open, returning to ready when the last task completes.
The web sidebar and mobile thread list both render idle sessions as 'Waiting' with a neutral style and an elapsed duration, treated as in-flight for display purposes.
Open task state is cleared on session exit or error so future sessions do not inherit the waiting state.
Behavioral Change: threads that previously resolved to ready while background tasks were open will now show as waiting until those tasks complete.

^{Macroscope summarized 368e0e1.}

coderabbitai · 2026-07-24T01:12:12Z

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 91fb2c98-8548-4670-a2cd-2cbb6e8a3eee

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

Create PR with unit tests
Commit unit tests in branch t3code/sidebar-waiting-state

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

macroscopeapp · 2026-07-24T01:16:45Z

Approvability

Verdict: Needs human review

New feature introducing a 'waiting' status with non-trivial server-side state tracking logic for background tasks. While well-tested, new user-facing behavior and runtime session status changes warrant human review.

^{You can customize Macroscope's approvability policy. Learn more.}

When the agent stops with background tasks (subagents, background bash, monitors) still running, the thread showed Done, then flicked back to Working when a task completion woke the agent. Track provider-reported open tasks in ingestion and park the session on the previously-unused "idle" status; sidebar v2 renders it as a grey "Waiting" with the same elapsed timer as Working. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Review fixes: gate the terminal-status task sweep behind the lifecycle guard so rejected stale events cannot erase the active turn's tasks; ignore task starts from a provider instance that doesn't match the projected session instead of letting them displace the current set; tombstone completed task ids so late/duplicate progress cannot re-open a finished task and park the thread on Waiting. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

A completed/failed final task wakes the agent (its notification is the wake signal), so Waiting flips straight to Working. A stopped final task is a kill — no wake follows — and previously left a live session parked on Waiting until teardown. Flip that case back to ready, and tombstone completions that outrun their start event. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

cursor

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 514fccf. Configure here.}

Tombstones exist to stop late/duplicate progress from resurrecting a finished task, but providers reuse task ids when an agent is resumed — a fresh task.started after completion is real work, not a replay. Progress stays blocked by the tombstone; an explicit start clears it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Real-data feedback round two: - Results render as a responsive grid (1/2/3 columns) instead of a full-width list. - While the sweep runs, the page shows only a progress count ("Reviewing your work — 7 of 18"); results reveal all at once when every thread is done, so triage happens in one pass over a stable layout instead of chasing cards as they pop in. - The model now returns a one-sentence imperative nextStep ("Review and merge PR #4415.") which becomes the card body — a direct answer to "what should I do here". Summaries are capped at one sentence and demoted to an info-icon tooltip. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…2.1-next Absorb CTM tip 408efa6 (Claude replay cleanup, ACP auth/fork provenance, derived-thread wake, fork-shell navigation wait) onto the pingdotgg#4415 Waiting sequence pinned at main ece0508. Conflict resolution (same intent as prior merge 616da6976): - Sidebar/threadList Waiting uses runtime.idle (CTM/orchestrator-v2 park) rather than session.idle from main pingdotgg#4415, including mobile tests. - Drop ProviderRuntimeIngestion (deleted on CTM; v2 uses orchestration-v2).

Update sidebar and mobile expectations for the pingdotgg#4415 Waiting status, repair command-suite settle/interrupt coverage after layer merges, and remove a duplicate settledAt JSON field that broke contracts typecheck.

…list The conversation timeline showed a Waiting line on desktop but nothing on iOS, and the mobile thread list showed no status at all. Mobile now derives the same normalized post-settlement background roster the server and web derive, appends the matching row to the thread feed, and gives the classic list resolver the Waiting pill its web counterpart already has. The conversation view prefers deriveThreadRuntime(projection), so activeWorkStartedAt went null at settlement and the row it gated simply vanished. The row is now driven by the roster rather than by run timing. The list gap was the same shape as the classic web sidebar gap this PR fixes: the v2 list sits behind a preference that is off, so the list that renders is the classic one, whose resolveThreadStatus had no Waiting branch. It now ranks a static muted Waiting pill below approvals, input, active work and failures, and above Plan Ready. Teaching the v2 list resolver about Waiting is pingdotgg#4415 waiting-presentation's concern, not this commit's. The derivation lives in deriveThreadPendingBackgroundWork rather than inline in the composer hook so the policy is unit tested. It passes runs, which the web call site in ChatView also passes, so turn items owned by a rolled_back run are abandoned on mobile exactly as they are on desktop. Without that argument the shared helper sees an empty rolled-back set and iOS would show Waiting where desktop does not. Working and Waiting are chosen from the parked runtime rather than from run timing alone. A successful run persists as waiting with a null completedAt until checkpoint capture lands, so deriveActiveWorkStartedAt keeps reporting a start time for that whole window; deriveThreadWorkingStartedAt suppresses it once the roster has parked the runtime at idle, which is how web sequences the two. A waiting run with an empty roster still reads Working, since that is checkpoint capture with no background work behind it. Two defensive points. Mobile restores projections from disk and shouldPersistThread persists only settled ones, so a cached projection is exactly the shape that reproduces a Waiting row for work that already finished; the roster is therefore gated on a live thread detail, and synchronizing is refused alongside cached because a subscription passes through it before any fresh projection arrives. And formatPendingBackgroundWorkLabel interpolates the raw description, which for a subagent item is the whole child prompt, so the label is clamped to two lines. Co-authored-by: codex <codex@users.noreply.github.com>

Update sidebar and mobile expectations for the pingdotgg#4415 Waiting status, repair command-suite settle/interrupt coverage after layer merges, and remove a duplicate settledAt JSON field that broke contracts typecheck.

juliusmarminge · 2026-07-30T15:37:00Z

Closing in favor of #2829 (orchestration V2).

#2829 deletes the V1 orchestration layer this PR builds on — apps/server/src/orchestration/**, provider/Layers/*Adapter.ts and provider/Services/** are removed and replaced by apps/server/src/orchestration-v2/**, with the IPC surface renamed to ORCHESTRATION_V2_WS_METHODS. The files this PR touches either no longer exist or are rewritten, so it can't be rebased — it would need reimplementing against the V2 adapters.

This is not a judgement on the change itself. Several of these are real gaps we still want fixed; the base just moved out from under them.

Once #2829 merges, please rebase onto main, port the change to the V2 equivalent, and reopen (or open a fresh PR). Ping me and I'll prioritise the review.

…list The conversation timeline showed a Waiting line on desktop but nothing on iOS, and the mobile thread list showed no status at all. Mobile now derives the same normalized post-settlement background roster the server and web derive, appends the matching row to the thread feed, and gives the classic list resolver the Waiting pill its web counterpart already has. The conversation view prefers deriveThreadRuntime(projection), so activeWorkStartedAt went null at settlement and the row it gated simply vanished. The row is now driven by the roster rather than by run timing. The list gap was the same shape as the classic web sidebar gap this PR fixes: the v2 list sits behind a preference that is off, so the list that renders is the classic one, whose resolveThreadStatus had no Waiting branch. It now ranks a static muted Waiting pill below approvals, input, active work and failures, and above Plan Ready. Teaching the v2 list resolver about Waiting is pingdotgg#4415 waiting-presentation's concern, not this commit's. The derivation lives in deriveThreadPendingBackgroundWork rather than inline in the composer hook so the policy is unit tested. It passes runs, which the web call site in ChatView also passes, so turn items owned by a rolled_back run are abandoned on mobile exactly as they are on desktop. Without that argument the shared helper sees an empty rolled-back set and iOS would show Waiting where desktop does not. Working and Waiting are chosen from the parked runtime rather than from run timing alone. A successful run persists as waiting with a null completedAt until checkpoint capture lands, so deriveActiveWorkStartedAt keeps reporting a start time for that whole window; deriveThreadWorkingStartedAt suppresses it once the roster has parked the runtime at idle, which is how web sequences the two. A waiting run with an empty roster still reads Working, since that is checkpoint capture with no background work behind it. Two defensive points. Mobile restores projections from disk and shouldPersistThread persists only settled ones, so a cached projection is exactly the shape that reproduces a Waiting row for work that already finished; the roster is therefore gated on a live thread detail, and synchronizing is refused alongside cached because a subscription passes through it before any fresh projection arrives. And formatPendingBackgroundWorkLabel interpolates the raw description, which for a subagent item is the whole child prompt, so the label is clamped to two lines. Co-authored-by: codex <codex@users.noreply.github.com>

Update sidebar and mobile expectations for the pingdotgg#4415 Waiting status, repair command-suite settle/interrupt coverage after layer merges, and remove a duplicate settledAt JSON field that broke contracts typecheck.

CTM's own subagent hiding (97a04be) skips delegated children inside buildThreadListV2Items, so the list is right, but hasAnyThreads still counts them. A user whose only live threads are subagent children therefore gets the in-list "No results" state instead of the full-page "No threads yet". Also corrects the threadListV2 header comment left by the CTM merge: pingdotgg#4415 sidebar-waiting-state describes Waiting as session.idle, while this line keys it off runtime.idle.

t3dotgg · 2026-07-24T01:12:04Z

When the agent stops while background tasks (subagents, background bash, monitors) are still running, the sidebar showed Done, then flicked back to Working when a task completion woke the agent (median 13s later, from local history).

Now ingestion tracks provider-reported open tasks per thread and parks the session on the previously-unused idle status when a turn ends with tasks still open. Sidebar v2 (web + mobile) renders it as a grey Waiting label with the same elapsed timer as Working; the row recedes like other in-flight states. Waiting flips directly to Working on wake-up — no intermediate Done.

Task set is keyed by provider instance and cleared on exit/stop/error, so stale tasks can't park a fresh session.
idle was already handled as "resting" by settlement, projection, and phase logic, so no contract or migration changes; old clients degrade to today's behavior.
Codex/OpenCode don't emit task events — behavior unchanged there.

🤖 Generated with Claude Code

Note

Medium Risk
Changes core session lifecycle in ProviderRuntimeIngestion (when threads show ready vs idle), with broad integration tests but no contract migration—incorrect task tracking could mislabel thread state across clients.

Overview
Threads that finish a turn while provider background tasks (monitors, subagents, etc.) are still open no longer flash Done before the wake-up turn. Provider runtime ingestion now tracks open tasks per thread and provider instance and parks the session on idle instead of ready when a turn ends with tasks still open; task state is cleared on session exit, error, and stale-instance guards, with tombstones for late events.

Web sidebar v2 and the mobile thread list map idle to a muted Waiting label (same elapsed timer as Working, in-flight row treatment). Successful task completion is expected to wake the agent without an intermediate ready; only a stopped last task returns Waiting to ready.

^{Reviewed by Cursor Bugbot for commit 368e0e1. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Add 'waiting' status for threads with open background tasks

Introduces a new idle session status that signals a thread is waiting on background tasks (e.g. PR monitors) rather than active user input or processing.
ProviderRuntimeIngestion tracks open tasks per thread/provider instance and transitions sessions to idle at rest when tasks remain open, returning to ready when the last task completes.
The web sidebar and mobile thread list both render idle sessions as 'Waiting' with a neutral style and an elapsed duration, treated as in-flight for display purposes.
Open task state is cleared on session exit or error so future sessions do not inherit the waiting state.
Behavioral Change: threads that previously resolved to ready while background tasks were open will now show as waiting until those tasks complete.

^{Macroscope summarized 368e0e1.}

coderabbitai · 2026-07-24T01:12:12Z

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 91fb2c98-8548-4670-a2cd-2cbb6e8a3eee

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

Create PR with unit tests
Commit unit tests in branch t3code/sidebar-waiting-state

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

macroscopeapp · 2026-07-24T01:16:45Z

Approvability

Verdict: Needs human review

New feature introducing a 'waiting' status with non-trivial server-side state tracking logic for background tasks. While well-tested, new user-facing behavior and runtime session status changes warrant human review.

^{You can customize Macroscope's approvability policy. Learn more.}

When the agent stops with background tasks (subagents, background bash, monitors) still running, the thread showed Done, then flicked back to Working when a task completion woke the agent. Track provider-reported open tasks in ingestion and park the session on the previously-unused "idle" status; sidebar v2 renders it as a grey "Waiting" with the same elapsed timer as Working. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Review fixes: gate the terminal-status task sweep behind the lifecycle guard so rejected stale events cannot erase the active turn's tasks; ignore task starts from a provider instance that doesn't match the projected session instead of letting them displace the current set; tombstone completed task ids so late/duplicate progress cannot re-open a finished task and park the thread on Waiting. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

A completed/failed final task wakes the agent (its notification is the wake signal), so Waiting flips straight to Working. A stopped final task is a kill — no wake follows — and previously left a live session parked on Waiting until teardown. Flip that case back to ready, and tombstone completions that outrun their start event. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

cursor

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 514fccf. Configure here.}

Tombstones exist to stop late/duplicate progress from resurrecting a finished task, but providers reuse task ids when an agent is resumed — a fresh task.started after completion is real work, not a replay. Progress stays blocked by the tombstone; an explicit start clears it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Real-data feedback round two: - Results render as a responsive grid (1/2/3 columns) instead of a full-width list. - While the sweep runs, the page shows only a progress count ("Reviewing your work — 7 of 18"); results reveal all at once when every thread is done, so triage happens in one pass over a stable layout instead of chasing cards as they pop in. - The model now returns a one-sentence imperative nextStep ("Review and merge PR #4415.") which becomes the card body — a direct answer to "what should I do here". Summaries are capped at one sentence and demoted to an info-icon tooltip. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…2.1-next Absorb CTM tip 408efa6 (Claude replay cleanup, ACP auth/fork provenance, derived-thread wake, fork-shell navigation wait) onto the pingdotgg#4415 Waiting sequence pinned at main ece0508. Conflict resolution (same intent as prior merge 616da6976): - Sidebar/threadList Waiting uses runtime.idle (CTM/orchestrator-v2 park) rather than session.idle from main pingdotgg#4415, including mobile tests. - Drop ProviderRuntimeIngestion (deleted on CTM; v2 uses orchestration-v2).

Update sidebar and mobile expectations for the pingdotgg#4415 Waiting status, repair command-suite settle/interrupt coverage after layer merges, and remove a duplicate settledAt JSON field that broke contracts typecheck.

…list The conversation timeline showed a Waiting line on desktop but nothing on iOS, and the mobile thread list showed no status at all. Mobile now derives the same normalized post-settlement background roster the server and web derive, appends the matching row to the thread feed, and gives the classic list resolver the Waiting pill its web counterpart already has. The conversation view prefers deriveThreadRuntime(projection), so activeWorkStartedAt went null at settlement and the row it gated simply vanished. The row is now driven by the roster rather than by run timing. The list gap was the same shape as the classic web sidebar gap this PR fixes: the v2 list sits behind a preference that is off, so the list that renders is the classic one, whose resolveThreadStatus had no Waiting branch. It now ranks a static muted Waiting pill below approvals, input, active work and failures, and above Plan Ready. Teaching the v2 list resolver about Waiting is pingdotgg#4415 waiting-presentation's concern, not this commit's. The derivation lives in deriveThreadPendingBackgroundWork rather than inline in the composer hook so the policy is unit tested. It passes runs, which the web call site in ChatView also passes, so turn items owned by a rolled_back run are abandoned on mobile exactly as they are on desktop. Without that argument the shared helper sees an empty rolled-back set and iOS would show Waiting where desktop does not. Working and Waiting are chosen from the parked runtime rather than from run timing alone. A successful run persists as waiting with a null completedAt until checkpoint capture lands, so deriveActiveWorkStartedAt keeps reporting a start time for that whole window; deriveThreadWorkingStartedAt suppresses it once the roster has parked the runtime at idle, which is how web sequences the two. A waiting run with an empty roster still reads Working, since that is checkpoint capture with no background work behind it. Two defensive points. Mobile restores projections from disk and shouldPersistThread persists only settled ones, so a cached projection is exactly the shape that reproduces a Waiting row for work that already finished; the roster is therefore gated on a live thread detail, and synchronizing is refused alongside cached because a subscription passes through it before any fresh projection arrives. And formatPendingBackgroundWorkLabel interpolates the raw description, which for a subagent item is the whole child prompt, so the label is clamped to two lines. Co-authored-by: codex <codex@users.noreply.github.com>

Update sidebar and mobile expectations for the pingdotgg#4415 Waiting status, repair command-suite settle/interrupt coverage after layer merges, and remove a duplicate settledAt JSON field that broke contracts typecheck.

juliusmarminge · 2026-07-30T15:37:00Z

Closing in favor of #2829 (orchestration V2).

#2829 deletes the V1 orchestration layer this PR builds on — apps/server/src/orchestration/**, provider/Layers/*Adapter.ts and provider/Services/** are removed and replaced by apps/server/src/orchestration-v2/**, with the IPC surface renamed to ORCHESTRATION_V2_WS_METHODS. The files this PR touches either no longer exist or are rewritten, so it can't be rebased — it would need reimplementing against the V2 adapters.

This is not a judgement on the change itself. Several of these are real gaps we still want fixed; the base just moved out from under them.

Once #2829 merges, please rebase onto main, port the change to the V2 equivalent, and reopen (or open a fresh PR). Ping me and I'll prioritise the review.

…list The conversation timeline showed a Waiting line on desktop but nothing on iOS, and the mobile thread list showed no status at all. Mobile now derives the same normalized post-settlement background roster the server and web derive, appends the matching row to the thread feed, and gives the classic list resolver the Waiting pill its web counterpart already has. The conversation view prefers deriveThreadRuntime(projection), so activeWorkStartedAt went null at settlement and the row it gated simply vanished. The row is now driven by the roster rather than by run timing. The list gap was the same shape as the classic web sidebar gap this PR fixes: the v2 list sits behind a preference that is off, so the list that renders is the classic one, whose resolveThreadStatus had no Waiting branch. It now ranks a static muted Waiting pill below approvals, input, active work and failures, and above Plan Ready. Teaching the v2 list resolver about Waiting is pingdotgg#4415 waiting-presentation's concern, not this commit's. The derivation lives in deriveThreadPendingBackgroundWork rather than inline in the composer hook so the policy is unit tested. It passes runs, which the web call site in ChatView also passes, so turn items owned by a rolled_back run are abandoned on mobile exactly as they are on desktop. Without that argument the shared helper sees an empty rolled-back set and iOS would show Waiting where desktop does not. Working and Waiting are chosen from the parked runtime rather than from run timing alone. A successful run persists as waiting with a null completedAt until checkpoint capture lands, so deriveActiveWorkStartedAt keeps reporting a start time for that whole window; deriveThreadWorkingStartedAt suppresses it once the roster has parked the runtime at idle, which is how web sequences the two. A waiting run with an empty roster still reads Working, since that is checkpoint capture with no background work behind it. Two defensive points. Mobile restores projections from disk and shouldPersistThread persists only settled ones, so a cached projection is exactly the shape that reproduces a Waiting row for work that already finished; the roster is therefore gated on a live thread detail, and synchronizing is refused alongside cached because a subscription passes through it before any fresh projection arrives. And formatPendingBackgroundWorkLabel interpolates the raw description, which for a subagent item is the whole child prompt, so the label is clamped to two lines. Co-authored-by: codex <codex@users.noreply.github.com>

Update sidebar and mobile expectations for the pingdotgg#4415 Waiting status, repair command-suite settle/interrupt coverage after layer merges, and remove a duplicate settledAt JSON field that broke contracts typecheck.

CTM's own subagent hiding (97a04be) skips delegated children inside buildThreadListV2Items, so the list is right, but hasAnyThreads still counts them. A user whose only live threads are subagent children therefore gets the in-list "No results" state instead of the full-page "No threads yet". Also corrects the threadListV2 header comment left by the CTM merge: pingdotgg#4415 sidebar-waiting-state describes Waiting as session.idle, while this line keys it off runtime.idle.

t3dotgg · 2026-07-24T01:12:04Z

When the agent stops while background tasks (subagents, background bash, monitors) are still running, the sidebar showed Done, then flicked back to Working when a task completion woke the agent (median 13s later, from local history).

Now ingestion tracks provider-reported open tasks per thread and parks the session on the previously-unused idle status when a turn ends with tasks still open. Sidebar v2 (web + mobile) renders it as a grey Waiting label with the same elapsed timer as Working; the row recedes like other in-flight states. Waiting flips directly to Working on wake-up — no intermediate Done.

Task set is keyed by provider instance and cleared on exit/stop/error, so stale tasks can't park a fresh session.
idle was already handled as "resting" by settlement, projection, and phase logic, so no contract or migration changes; old clients degrade to today's behavior.
Codex/OpenCode don't emit task events — behavior unchanged there.

🤖 Generated with Claude Code

Note

Medium Risk
Changes core session lifecycle in ProviderRuntimeIngestion (when threads show ready vs idle), with broad integration tests but no contract migration—incorrect task tracking could mislabel thread state across clients.

Overview
Threads that finish a turn while provider background tasks (monitors, subagents, etc.) are still open no longer flash Done before the wake-up turn. Provider runtime ingestion now tracks open tasks per thread and provider instance and parks the session on idle instead of ready when a turn ends with tasks still open; task state is cleared on session exit, error, and stale-instance guards, with tombstones for late events.

Web sidebar v2 and the mobile thread list map idle to a muted Waiting label (same elapsed timer as Working, in-flight row treatment). Successful task completion is expected to wake the agent without an intermediate ready; only a stopped last task returns Waiting to ready.

^{Reviewed by Cursor Bugbot for commit 368e0e1. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Add 'waiting' status for threads with open background tasks

Introduces a new idle session status that signals a thread is waiting on background tasks (e.g. PR monitors) rather than active user input or processing.
ProviderRuntimeIngestion tracks open tasks per thread/provider instance and transitions sessions to idle at rest when tasks remain open, returning to ready when the last task completes.
The web sidebar and mobile thread list both render idle sessions as 'Waiting' with a neutral style and an elapsed duration, treated as in-flight for display purposes.
Open task state is cleared on session exit or error so future sessions do not inherit the waiting state.
Behavioral Change: threads that previously resolved to ready while background tasks were open will now show as waiting until those tasks complete.

^{Macroscope summarized 368e0e1.}

coderabbitai · 2026-07-24T01:12:12Z

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 91fb2c98-8548-4670-a2cd-2cbb6e8a3eee

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

Create PR with unit tests
Commit unit tests in branch t3code/sidebar-waiting-state

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

macroscopeapp · 2026-07-24T01:16:45Z

Approvability

Verdict: Needs human review

New feature introducing a 'waiting' status with non-trivial server-side state tracking logic for background tasks. While well-tested, new user-facing behavior and runtime session status changes warrant human review.

^{You can customize Macroscope's approvability policy. Learn more.}

When the agent stops with background tasks (subagents, background bash, monitors) still running, the thread showed Done, then flicked back to Working when a task completion woke the agent. Track provider-reported open tasks in ingestion and park the session on the previously-unused "idle" status; sidebar v2 renders it as a grey "Waiting" with the same elapsed timer as Working. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Review fixes: gate the terminal-status task sweep behind the lifecycle guard so rejected stale events cannot erase the active turn's tasks; ignore task starts from a provider instance that doesn't match the projected session instead of letting them displace the current set; tombstone completed task ids so late/duplicate progress cannot re-open a finished task and park the thread on Waiting. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

A completed/failed final task wakes the agent (its notification is the wake signal), so Waiting flips straight to Working. A stopped final task is a kill — no wake follows — and previously left a live session parked on Waiting until teardown. Flip that case back to ready, and tombstone completions that outrun their start event. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

cursor

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 514fccf. Configure here.}

Tombstones exist to stop late/duplicate progress from resurrecting a finished task, but providers reuse task ids when an agent is resumed — a fresh task.started after completion is real work, not a replay. Progress stays blocked by the tombstone; an explicit start clears it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Real-data feedback round two: - Results render as a responsive grid (1/2/3 columns) instead of a full-width list. - While the sweep runs, the page shows only a progress count ("Reviewing your work — 7 of 18"); results reveal all at once when every thread is done, so triage happens in one pass over a stable layout instead of chasing cards as they pop in. - The model now returns a one-sentence imperative nextStep ("Review and merge PR #4415.") which becomes the card body — a direct answer to "what should I do here". Summaries are capped at one sentence and demoted to an info-icon tooltip. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…2.1-next Absorb CTM tip 408efa6 (Claude replay cleanup, ACP auth/fork provenance, derived-thread wake, fork-shell navigation wait) onto the pingdotgg#4415 Waiting sequence pinned at main ece0508. Conflict resolution (same intent as prior merge 616da6976): - Sidebar/threadList Waiting uses runtime.idle (CTM/orchestrator-v2 park) rather than session.idle from main pingdotgg#4415, including mobile tests. - Drop ProviderRuntimeIngestion (deleted on CTM; v2 uses orchestration-v2).

Update sidebar and mobile expectations for the pingdotgg#4415 Waiting status, repair command-suite settle/interrupt coverage after layer merges, and remove a duplicate settledAt JSON field that broke contracts typecheck.

…list The conversation timeline showed a Waiting line on desktop but nothing on iOS, and the mobile thread list showed no status at all. Mobile now derives the same normalized post-settlement background roster the server and web derive, appends the matching row to the thread feed, and gives the classic list resolver the Waiting pill its web counterpart already has. The conversation view prefers deriveThreadRuntime(projection), so activeWorkStartedAt went null at settlement and the row it gated simply vanished. The row is now driven by the roster rather than by run timing. The list gap was the same shape as the classic web sidebar gap this PR fixes: the v2 list sits behind a preference that is off, so the list that renders is the classic one, whose resolveThreadStatus had no Waiting branch. It now ranks a static muted Waiting pill below approvals, input, active work and failures, and above Plan Ready. Teaching the v2 list resolver about Waiting is pingdotgg#4415 waiting-presentation's concern, not this commit's. The derivation lives in deriveThreadPendingBackgroundWork rather than inline in the composer hook so the policy is unit tested. It passes runs, which the web call site in ChatView also passes, so turn items owned by a rolled_back run are abandoned on mobile exactly as they are on desktop. Without that argument the shared helper sees an empty rolled-back set and iOS would show Waiting where desktop does not. Working and Waiting are chosen from the parked runtime rather than from run timing alone. A successful run persists as waiting with a null completedAt until checkpoint capture lands, so deriveActiveWorkStartedAt keeps reporting a start time for that whole window; deriveThreadWorkingStartedAt suppresses it once the roster has parked the runtime at idle, which is how web sequences the two. A waiting run with an empty roster still reads Working, since that is checkpoint capture with no background work behind it. Two defensive points. Mobile restores projections from disk and shouldPersistThread persists only settled ones, so a cached projection is exactly the shape that reproduces a Waiting row for work that already finished; the roster is therefore gated on a live thread detail, and synchronizing is refused alongside cached because a subscription passes through it before any fresh projection arrives. And formatPendingBackgroundWorkLabel interpolates the raw description, which for a subagent item is the whole child prompt, so the label is clamped to two lines. Co-authored-by: codex <codex@users.noreply.github.com>

Update sidebar and mobile expectations for the pingdotgg#4415 Waiting status, repair command-suite settle/interrupt coverage after layer merges, and remove a duplicate settledAt JSON field that broke contracts typecheck.

juliusmarminge · 2026-07-30T15:37:00Z

Closing in favor of #2829 (orchestration V2).

#2829 deletes the V1 orchestration layer this PR builds on — apps/server/src/orchestration/**, provider/Layers/*Adapter.ts and provider/Services/** are removed and replaced by apps/server/src/orchestration-v2/**, with the IPC surface renamed to ORCHESTRATION_V2_WS_METHODS. The files this PR touches either no longer exist or are rewritten, so it can't be rebased — it would need reimplementing against the V2 adapters.

This is not a judgement on the change itself. Several of these are real gaps we still want fixed; the base just moved out from under them.

Once #2829 merges, please rebase onto main, port the change to the V2 equivalent, and reopen (or open a fresh PR). Ping me and I'll prioritise the review.

…list The conversation timeline showed a Waiting line on desktop but nothing on iOS, and the mobile thread list showed no status at all. Mobile now derives the same normalized post-settlement background roster the server and web derive, appends the matching row to the thread feed, and gives the classic list resolver the Waiting pill its web counterpart already has. The conversation view prefers deriveThreadRuntime(projection), so activeWorkStartedAt went null at settlement and the row it gated simply vanished. The row is now driven by the roster rather than by run timing. The list gap was the same shape as the classic web sidebar gap this PR fixes: the v2 list sits behind a preference that is off, so the list that renders is the classic one, whose resolveThreadStatus had no Waiting branch. It now ranks a static muted Waiting pill below approvals, input, active work and failures, and above Plan Ready. Teaching the v2 list resolver about Waiting is pingdotgg#4415 waiting-presentation's concern, not this commit's. The derivation lives in deriveThreadPendingBackgroundWork rather than inline in the composer hook so the policy is unit tested. It passes runs, which the web call site in ChatView also passes, so turn items owned by a rolled_back run are abandoned on mobile exactly as they are on desktop. Without that argument the shared helper sees an empty rolled-back set and iOS would show Waiting where desktop does not. Working and Waiting are chosen from the parked runtime rather than from run timing alone. A successful run persists as waiting with a null completedAt until checkpoint capture lands, so deriveActiveWorkStartedAt keeps reporting a start time for that whole window; deriveThreadWorkingStartedAt suppresses it once the roster has parked the runtime at idle, which is how web sequences the two. A waiting run with an empty roster still reads Working, since that is checkpoint capture with no background work behind it. Two defensive points. Mobile restores projections from disk and shouldPersistThread persists only settled ones, so a cached projection is exactly the shape that reproduces a Waiting row for work that already finished; the roster is therefore gated on a live thread detail, and synchronizing is refused alongside cached because a subscription passes through it before any fresh projection arrives. And formatPendingBackgroundWorkLabel interpolates the raw description, which for a subagent item is the whole child prompt, so the label is clamped to two lines. Co-authored-by: codex <codex@users.noreply.github.com>

Update sidebar and mobile expectations for the pingdotgg#4415 Waiting status, repair command-suite settle/interrupt coverage after layer merges, and remove a duplicate settledAt JSON field that broke contracts typecheck.

CTM's own subagent hiding (97a04be) skips delegated children inside buildThreadListV2Items, so the list is right, but hasAnyThreads still counts them. A user whose only live threads are subagent children therefore gets the in-list "No results" state instead of the full-page "No threads yet". Also corrects the threadListV2 header comment left by the CTM merge: pingdotgg#4415 sidebar-waiting-state describes Waiting as session.idle, while this line keys it off runtime.idle.

github-actionsBot added vouch:trusted PR author is trusted by repo permissions or the VOUCHED list. size:L 100-499 changed lines (additions + deletions). labels Jul 24, 2026

macroscopeappBot reviewed Jul 24, 2026
View reviewed changes

Comment threadapps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts Outdated
Comment threadapps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts Outdated

cursorBot reviewed Jul 24, 2026
View reviewed changes

Comment threadapps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts Outdated
Comment threadapps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts

t3dotgg changed the title ~~Show Waiting state for threads with open background tasks~~feat: "waiting" status for threads with open background tasks (i.e. pr monitors)Jul 24, 2026

t3dotggand others added 2 commits July 23, 2026 22:21

t3dotgg force-pushed the t3code/sidebar-waiting-state branch from bec6dc6 to 528adb2Compare July 24, 2026 05:22

macroscopeappBot reviewed Jul 24, 2026
View reviewed changes

Comment threadapps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts

cursorBot reviewed Jul 24, 2026
View reviewed changes

Comment threadapps/web/src/components/SidebarV2.tsx

cursorBot reviewed Jul 24, 2026
View reviewed changes

Comment threadapps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts

mwolson mentioned this pull request Jul 24, 2026
feat(orchestrator): Surface waiting background work #4378
Merged

t3dotgg mentioned this pull request Jul 30, 2026
feat: show a waiting state when background tasks outlive the turn #4255
Closed

juliusmarminge closed this Jul 30, 2026

github-actionsBot added vouch:trusted PR author is trusted by repo permissions or the VOUCHED list. size:L 100-499 changed lines (additions + deletions). labels Jul 24, 2026

macroscopeappBot reviewed Jul 24, 2026
View reviewed changes

Comment threadapps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts Outdated
Comment threadapps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts Outdated

cursorBot reviewed Jul 24, 2026
View reviewed changes

Comment threadapps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts Outdated
Comment threadapps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts

t3dotgg changed the title ~~Show Waiting state for threads with open background tasks~~feat: "waiting" status for threads with open background tasks (i.e. pr monitors)Jul 24, 2026

t3dotggand others added 2 commits July 23, 2026 22:21

t3dotgg force-pushed the t3code/sidebar-waiting-state branch from bec6dc6 to 528adb2Compare July 24, 2026 05:22

macroscopeappBot reviewed Jul 24, 2026
View reviewed changes

Comment threadapps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts

cursorBot reviewed Jul 24, 2026
View reviewed changes

Comment threadapps/web/src/components/SidebarV2.tsx

cursorBot reviewed Jul 24, 2026
View reviewed changes

Comment threadapps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts

mwolson mentioned this pull request Jul 24, 2026
feat(orchestrator): Surface waiting background work #4378
Merged

t3dotgg mentioned this pull request Jul 30, 2026
feat: show a waiting state when background tasks outlive the turn #4255
Closed

juliusmarminge closed this Jul 30, 2026

github-actionsBot added vouch:trusted PR author is trusted by repo permissions or the VOUCHED list. size:L 100-499 changed lines (additions + deletions). labels Jul 24, 2026

macroscopeappBot reviewed Jul 24, 2026
View reviewed changes

Comment threadapps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts Outdated
Comment threadapps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts Outdated

cursorBot reviewed Jul 24, 2026
View reviewed changes

Comment threadapps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts Outdated
Comment threadapps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts

t3dotgg changed the title ~~Show Waiting state for threads with open background tasks~~feat: "waiting" status for threads with open background tasks (i.e. pr monitors)Jul 24, 2026

t3dotggand others added 2 commits July 23, 2026 22:21

t3dotgg force-pushed the t3code/sidebar-waiting-state branch from bec6dc6 to 528adb2Compare July 24, 2026 05:22

macroscopeappBot reviewed Jul 24, 2026
View reviewed changes

Comment threadapps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts

cursorBot reviewed Jul 24, 2026
View reviewed changes

Comment threadapps/web/src/components/SidebarV2.tsx

cursorBot reviewed Jul 24, 2026
View reviewed changes

Comment threadapps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts

mwolson mentioned this pull request Jul 24, 2026
feat(orchestrator): Surface waiting background work #4378
Merged

t3dotgg mentioned this pull request Jul 30, 2026
feat: show a waiting state when background tasks outlive the turn #4255
Closed

juliusmarminge closed this Jul 30, 2026

github-actionsBot added vouch:trusted PR author is trusted by repo permissions or the VOUCHED list. size:L 100-499 changed lines (additions + deletions). labels Jul 24, 2026

macroscopeappBot reviewed Jul 24, 2026
View reviewed changes

Comment threadapps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts Outdated
Comment threadapps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts Outdated

cursorBot reviewed Jul 24, 2026
View reviewed changes

Comment threadapps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts Outdated
Comment threadapps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts

t3dotgg changed the title ~~Show Waiting state for threads with open background tasks~~feat: "waiting" status for threads with open background tasks (i.e. pr monitors)Jul 24, 2026

t3dotggand others added 2 commits July 23, 2026 22:21

t3dotgg force-pushed the t3code/sidebar-waiting-state branch from bec6dc6 to 528adb2Compare July 24, 2026 05:22

macroscopeappBot reviewed Jul 24, 2026
View reviewed changes

Comment threadapps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts

cursorBot reviewed Jul 24, 2026
View reviewed changes

Comment threadapps/web/src/components/SidebarV2.tsx

cursorBot reviewed Jul 24, 2026
View reviewed changes

Comment threadapps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts

mwolson mentioned this pull request Jul 24, 2026
feat(orchestrator): Surface waiting background work #4378
Merged

t3dotgg mentioned this pull request Jul 30, 2026
feat: show a waiting state when background tasks outlive the turn #4255
Closed

juliusmarminge closed this Jul 30, 2026

github-actionsBot added vouch:trusted PR author is trusted by repo permissions or the VOUCHED list. size:L 100-499 changed lines (additions + deletions). labels Jul 24, 2026

macroscopeappBot reviewed Jul 24, 2026
View reviewed changes

Comment threadapps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts Outdated
Comment threadapps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts Outdated

cursorBot reviewed Jul 24, 2026
View reviewed changes

Comment threadapps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts Outdated
Comment threadapps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts

t3dotgg changed the title ~~Show Waiting state for threads with open background tasks~~feat: "waiting" status for threads with open background tasks (i.e. pr monitors)Jul 24, 2026

t3dotggand others added 2 commits July 23, 2026 22:21

t3dotgg force-pushed the t3code/sidebar-waiting-state branch from bec6dc6 to 528adb2Compare July 24, 2026 05:22

macroscopeappBot reviewed Jul 24, 2026
View reviewed changes

Comment threadapps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts

cursorBot reviewed Jul 24, 2026
View reviewed changes

Comment threadapps/web/src/components/SidebarV2.tsx

cursorBot reviewed Jul 24, 2026
View reviewed changes

Comment threadapps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts

mwolson mentioned this pull request Jul 24, 2026
feat(orchestrator): Surface waiting background work #4378
Merged

t3dotgg mentioned this pull request Jul 30, 2026
feat: show a waiting state when background tasks outlive the turn #4255
Closed

juliusmarminge closed this Jul 30, 2026

github-actionsBot added vouch:trusted PR author is trusted by repo permissions or the VOUCHED list. size:L 100-499 changed lines (additions + deletions). labels Jul 24, 2026

macroscopeappBot reviewed Jul 24, 2026
View reviewed changes

Comment threadapps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts Outdated
Comment threadapps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts Outdated

cursorBot reviewed Jul 24, 2026
View reviewed changes

Comment threadapps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts Outdated
Comment threadapps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts

t3dotgg changed the title ~~Show Waiting state for threads with open background tasks~~feat: "waiting" status for threads with open background tasks (i.e. pr monitors)Jul 24, 2026

t3dotggand others added 2 commits July 23, 2026 22:21

t3dotgg force-pushed the t3code/sidebar-waiting-state branch from bec6dc6 to 528adb2Compare July 24, 2026 05:22

macroscopeappBot reviewed Jul 24, 2026
View reviewed changes

Comment threadapps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts

cursorBot reviewed Jul 24, 2026
View reviewed changes

Comment threadapps/web/src/components/SidebarV2.tsx

cursorBot reviewed Jul 24, 2026
View reviewed changes

Comment threadapps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts

mwolson mentioned this pull request Jul 24, 2026
feat(orchestrator): Surface waiting background work #4378
Merged

t3dotgg mentioned this pull request Jul 30, 2026
feat: show a waiting state when background tasks outlive the turn #4255
Closed

juliusmarminge closed this Jul 30, 2026

github-actionsBot added vouch:trusted PR author is trusted by repo permissions or the VOUCHED list. size:L 100-499 changed lines (additions + deletions). labels Jul 24, 2026

macroscopeappBot reviewed Jul 24, 2026
View reviewed changes

Comment threadapps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts Outdated
Comment threadapps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts Outdated

cursorBot reviewed Jul 24, 2026
View reviewed changes

Comment threadapps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts Outdated
Comment threadapps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts

t3dotgg changed the title ~~Show Waiting state for threads with open background tasks~~feat: "waiting" status for threads with open background tasks (i.e. pr monitors)Jul 24, 2026

t3dotggand others added 2 commits July 23, 2026 22:21

t3dotgg force-pushed the t3code/sidebar-waiting-state branch from bec6dc6 to 528adb2Compare July 24, 2026 05:22

macroscopeappBot reviewed Jul 24, 2026
View reviewed changes

Comment threadapps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts

cursorBot reviewed Jul 24, 2026
View reviewed changes

Comment threadapps/web/src/components/SidebarV2.tsx

cursorBot reviewed Jul 24, 2026
View reviewed changes

Comment threadapps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts

mwolson mentioned this pull request Jul 24, 2026
feat(orchestrator): Surface waiting background work #4378
Merged

t3dotgg mentioned this pull request Jul 30, 2026
feat: show a waiting state when background tasks outlive the turn #4255
Closed

juliusmarminge closed this Jul 30, 2026

github-actionsBot added vouch:trusted PR author is trusted by repo permissions or the VOUCHED list. size:L 100-499 changed lines (additions + deletions). labels Jul 24, 2026

macroscopeappBot reviewed Jul 24, 2026
View reviewed changes

Comment threadapps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts Outdated
Comment threadapps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts Outdated

cursorBot reviewed Jul 24, 2026
View reviewed changes

Comment threadapps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts Outdated
Comment threadapps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts

t3dotgg changed the title ~~Show Waiting state for threads with open background tasks~~feat: "waiting" status for threads with open background tasks (i.e. pr monitors)Jul 24, 2026

t3dotggand others added 2 commits July 23, 2026 22:21

t3dotgg force-pushed the t3code/sidebar-waiting-state branch from bec6dc6 to 528adb2Compare July 24, 2026 05:22

macroscopeappBot reviewed Jul 24, 2026
View reviewed changes

Comment threadapps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts

cursorBot reviewed Jul 24, 2026
View reviewed changes

Comment threadapps/web/src/components/SidebarV2.tsx

cursorBot reviewed Jul 24, 2026
View reviewed changes

Comment threadapps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts

mwolson mentioned this pull request Jul 24, 2026
feat(orchestrator): Surface waiting background work #4378
Merged

t3dotgg mentioned this pull request Jul 30, 2026
feat: show a waiting state when background tasks outlive the turn #4255
Closed

juliusmarminge closed this Jul 30, 2026

Uh oh!

Conversation

t3dotgg commented Jul 24, 2026• edited by macroscopeapp BotLoading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Add 'waiting' status for threads with open background tasks

Uh oh!

coderabbitaiBot commented Jul 24, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Review skipped

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

macroscopeappBot commented Jul 24, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Approvability

Uh oh!

Uh oh!

Uh oh!

cursorBot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

juliusmarminge commented Jul 30, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

t3dotgg commented Jul 24, 2026• edited by macroscopeapp BotLoading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Add 'waiting' status for threads with open background tasks

Uh oh!

coderabbitaiBot commented Jul 24, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Review skipped

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

macroscopeappBot commented Jul 24, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Approvability

Uh oh!

Uh oh!

Uh oh!

cursorBot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

juliusmarminge commented Jul 30, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

t3dotgg commented Jul 24, 2026• edited by macroscopeapp BotLoading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Add 'waiting' status for threads with open background tasks

Uh oh!

coderabbitaiBot commented Jul 24, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Review skipped

Uh oh!

Uh oh!

Uh oh!

t3dotgg commented Jul 24, 2026•
edited by macroscopeapp Bot
Loading

coderabbitaiBot commented Jul 24, 2026•
edited
Loading

macroscopeappBot commented Jul 24, 2026•
edited
Loading

t3dotgg commented Jul 24, 2026•
edited by macroscopeapp Bot
Loading

coderabbitaiBot commented Jul 24, 2026•
edited
Loading

macroscopeappBot commented Jul 24, 2026•
edited
Loading

t3dotgg commented Jul 24, 2026•
edited by macroscopeapp Bot
Loading

coderabbitaiBot commented Jul 24, 2026•
edited
Loading

macroscopeappBot commented Jul 24, 2026•
edited
Loading

t3dotgg commented Jul 24, 2026•
edited by macroscopeapp Bot
Loading

coderabbitaiBot commented Jul 24, 2026•
edited
Loading

macroscopeappBot commented Jul 24, 2026•
edited
Loading