Repository navigation
After a restart, an agent tab asks the terminal host what is running, never "Couldn't confirm the agent started" - #28043
Conversation
… never "couldn't confirm" A launch pane's spawn read the launch record (and the tab's saved outcome) when no launch was running for it, so a row left pending by a quit showed "Couldn't confirm the agent started." The record never observes the process; the terminal host does. With no launch running in this process the pane now spawns exactly like any tab: a live agent reattaches, an exited or absent one gives a fresh shell, and a gone daemon shows the normal unavailable state. - the running launch tells its pane how it ended in memory (finish carries the verdict); only a definite failure says "couldn't start", an unknown outcome leaves an ordinary pane - deleted: agentLaunchPaneVerdictFromRecord, listAgentSessionOperationRowsOwningPane, the `unconfirmed` verdict and its notice string, the tab's persisted launch pane, ownedPane writes - rows written by an older build that carry ownedPane are ignored; they expire with the row
f20e4ed to
4f4ea55
Compare
… notice for the session and never spawns a shell under it; a reload saves only a pending launch
…ing-back case the IPC suite already pins
… session's launch pane with a typed tab
…dn't confirm the agent started" for the session, and attaches its agent if it turns up
… its pane until it quits, so the pane never spawns a shell under its notice; the window's spawn gate goes
…osed during its launch, moved to another tab, or its workspace is removed; comments say what an unknown outcome and a reload now do
Status: review, live QA and CI done; ready for reviewThe problem. When Orca quit while an agent tab was still starting, the tab kept a bookkeeping record of the launch. After the restart it read that record instead of asking the terminal service what was actually running, so it could say "Couldn't confirm the agent started" even when the agent was fine. What changes for you. One thing: after a restart you no longer see "Couldn't confirm the agent started". A restored tab asks the terminal service like every other tab: a running agent reattaches, an exited one gives a normal terminal, a gone terminal service shows its usual unavailable state. Everything during a session is as today (both "The agent couldn't start" and "Couldn't confirm the agent started." with Copy prompt and no shell under them). One edge, listed in the body: in a new repo where no tab has been split or closed yet, a failed launch's tab comes back after a restart as a plain terminal (main showed its notice with no terminal). Review. This PR started as a larger change (agent tabs starting their own terminal from the host's plan) and was split; this part is only the restart change, based on
Live QA (hidden macOS test copies of Orca, the real Claude Code, scripted drivers;
CI. Green at 0c745d9 (static analysis + typecheck, 5 test shards, package incl. Windows). An earlier red run was Size. Production −115, tests −232 lines vs Deferred (P3, not fixed here).
Not verified. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Priority: ⬇️ Low Merge Risk: ⚪ Minimal · up to
|
ELI5
When Orca quits while an agent tab is still starting, the tab used to remember "a launch was in progress here" in a bookkeeping record. After the restart it read that record instead of checking whether the agent was actually running, and often said "Couldn't confirm the agent started" even when the agent was fine.
Now a restored tab simply asks the terminal service, like every other tab: if the agent is still running you see it, if it exited you get a normal terminal, and if the terminal service itself is gone you see its usual "unavailable" state.
What Changed
The problem. An agent tab that is still starting (an AI button such as "Fix checks", a phone or CLI launch shown on the desktop) has a pane the host laid out before the agent existed. Orca wrote two records about it: the launch's row in the agent-session journal named the pane (
ownedPane), and the saved workspace kept the tab's launch state (agentLaunchPane, with its outcome). After a restart, the pane's spawn read those records instead of the terminal host. A row left pending by the quit cannot tell whether the agent started, so the tab said "Couldn't confirm the agent started." The record never sees the process; the terminal host does.What you'll see differently (every platform): no more "Couldn't confirm the agent started" after a restart. A tab that was launching an agent when Orca quit behaves like any tab: a live agent reattaches, an exited one gives a fresh shell, and a gone terminal service shows its normal unavailable state.
Nothing else changes. During the session a failed launch's "The agent couldn't start" and an unknown one's "Couldn't confirm the agent started." both show exactly as today, with Copy prompt and no shell under them, even if the pane mounts again (for example after switching workspaces); the second still attaches the agent if it turns up. A failed launch's tab is still gone after a reload or restart in any repo where a tab has been split or closed, as today. In a new repo where no tab has been split or closed yet, a failed launch's tab comes back after a restart as a plain terminal (main showed its "The agent couldn't start" notice with no terminal). How launches start, the phone, SSH and paired servers are as today.
Mechanism.
agentLaunchPaneVerdictFromRecord,listAgentSessionOperationRowsOwningPane), and theownedPanethe journal wrote with each claim.ownedPaneare ignored and expire with the row (24 hours).Why
The terminal host already knows whether a pane's process is alive. Storing a second copy of that fact in the launch record, and believing it after a restart, is what produced the wrong notice. Deriving the state from the terminal host removes the stored copy and the "work still owed" record that nothing re-derived. A restored tab asking the terminal host what is running is the common pattern.
The alternative was to keep the records and teach the restart path to doubt them, for example by checking the daemon first and the record second. That keeps two sources of truth and the code that reconciles them.
Linked Issue
Part of the launch-convergence plan (restart step). It is based on
mainand does not depend on C1 (#27692).Visual Proof
Live QA on hidden test copies of Orca with the real Claude Code, comparing this branch with
main(full table in the status comment below).After a restart with the agent still running, the tab reattaches to the same Claude process, with its scrollback and no notice:
A launch started from the CLI whose outcome was never confirmed, after a restart: a plain terminal, no "Couldn't confirm the agent started":
Testing
I manually tested these changes locally (live QA on hidden macOS test copies with the real Claude Code; see the status comment)
Automated tests added/updated
Restart. A restored pane, which is what a launch pane is after a restart (nothing about its launch is restored), spawns as an ordinary pane for a live, an exited and a gone terminal host.
Running launch. While a launch runs, its pane waits for it and then attaches or says a definite failure typed. An unknown outcome says "Couldn't confirm the agent started.", attaches if the agent turns up, and after a restart is an ordinary pane.
Same session. A spawn of a failed launch's pane after its verdict gets the same refusal from main and starts no shell; closing the pane (also while its launch still runs), moving it to another tab, removing its workspace, or a process holding it, forgets it; a restart forgets everything.
Saved state. The saved session keeps a pending launch pane and never its outcome; a restart drops it; a journal claim no longer writes
ownedPane.Verified on
mainat2233fd36691:tc:nodeandtc:webpass;check:code-quality:changed,oxlintand the localization checks pass; the changed modules' tests and the launch-convergence characterization suites pass (100 files, 2728 tests, includingorca-runtime.test.ts, which runs the runtime spec parts).Size
Measured with
git diff --numstat <base> HEAD -- src, TypeScript only; test files (*.test.ts(x),__tests__/,*.spec.ts,*.test-fixture.ts) count as tests and the locale JSON files on their own. Againstmain(2233fd36691): production −115, tests −232, locale strings 0.AI Disclosure
Review
Agent skill upstream boundary
Notes
Ensure no issues in: Security, Cross-platoform support (Linux, Windows, Mac), Remote SSH, Mobile, general backwards compatibility, performance
Checklist
N/Awith reason (live QA follows)pnpm lint,pnpm typecheck,pnpm test, andpnpm buildpass (or CI will cover; local preferred)