[brennanb2025]

	Files	Added	Deleted	Net
Test	5	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​224	$\color{#cf222e}{\Huge{\mathbf{−}}}$​2	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​222
Prod	8	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​81	$\color{#cf222e}{\Huge{\mathbf{−}}}$​16	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​65

ELI5

When you pick an agent from the "+" menu, Quick Launch, the floating panel, the new-agent shortcut or a dashboard, the window has always started that agent itself, by queuing a command and typing it into the new terminal. The AI buttons already work differently: they ask Orca's launch service (the "host", the part of Orca that runs the workspace's terminals) to start the agent. This PR makes those plain new-tab launches use the same host launch the AI buttons use. You should see exactly the same tab, agent and folder as before.

What Changed

Problem. Desktop new-tab agent launches still ran in the window, not through the shared host launch (agent.launch) that the AI buttons, CLI and phone already use. Two ways of starting the same agent means every launch fix has to land twice. This is the last caller group in phase 1 of launch unification, and Brennan asked for strict parity: move it with no user-visible change, then fix bugs after the move.

User-facing change. None intended, apart from one small difference listed below. Same single new tab in the same group and pane, same agent, arguments, environment and working folder, same selection (a floating launch still leaves the main window alone). In tests the agent's first output appeared about 160 ms sooner.

Mechanism (renderer only, no host or wire changes).

• The "+" menu agent items, Quick Launch's "Launch agent …", the floating panel's "+" and its shortcut, the new-agent shortcut and dashboard spawn mark their launch as a plain new-tab pick.
• launchAgentInNewTab sends such a launch through main's existing launchAgentThroughHost, the same route the AI buttons use, but only when that route already matches main's own launch:
  • there is no prompt;
  • the chat default is off;
  • the agent is enabled (main's window never read the disabled list here);
  • the workspace is not on SSH (main's pane connects first and waits for the remote shell);
  • the window would launch it on this machine's own platform (for example, a WSL path on Windows launches as Linux from the window).
• Everything else keeps main's path unchanged, including every launch with a prompt (saved Quick Commands, Notes, AI buttons).
• A floating launch asks the host for a background launch, so the main window's selection doesn't move.
• If the host can't start a no-prompt launch, the existing "couldn't start" notice appears without the "Copy prompt" button, since there is no prompt to copy.

One user-visible difference (intended). If you close a just-launched agent tab within about a quarter second of clicking, main silently cancels the launch. Now the agent may still start, and main's usual "Stop running command?" prompt appears. That is exactly what main's AI-button launches do today, because this PR uses their route. "Stop and Close" keeps the tab closed with no leftover process.

Folded in. #26364 (host-side delivery of the first prompt) is closed; at strict parity it isn't needed, because the window keeps delivering prompts exactly as main does.

Why

Reusing the route main already runs for the AI buttons is the smallest move that gets these launches onto the host. The earlier version of this PR (and #26364, #26168, #26173) also changed how prompts are delivered and fixed several existing bugs along the way. Brennan asked to separate those: migrate at parity first, fix bugs after. So this version adds no new host behaviour, keeps every case where the host route still differs from the window on main's path, and leaves the fixes for follow-ups.

Linked Issue

Launch unification, phase 1 (last caller group). Replaces the earlier stacked version of this PR and #26364.

Visual Proof

Hidden test builds with a stand-in agent (it replays a recorded agent screen, so the path and banner text in the terminal come from the recording, not a real agent). Main 1a2ccb856e2 vs this PR 533d54c0e4b.

	Before (main)	After (this PR)
"+" -> Claude: one new tab in the same group, agent running
Closing a tab whose agent has started: main's existing prompt on both (main: close at +409 ms; this PR: close at +150 ms, where main would have cancelled silently). Cropped to the dialog

Testing

• I manually tested these changes (hidden isolated macOS builds driven through the real UI, local and SSH; not on this desktop)
• Automated tests added/updated

Live QA, main 1a2ccb856e2 (this PR's merge-base) vs this PR, same stand-in agents and steps on both:

Check	Main	This PR
"+" -> Claude, Quick Launch (click and Enter), floating "+" and shortcut, ⌘⌥T	one tab, right group and folder, selection as before	same
Saved Quick Command with a prompt (café ✓ marker)	marker once as the agent's argument, 153 B of other input	byte-for-byte the same
SSH container: connect, "+", Quick Launch, Quick Command	one remote agent per click, prompt once	same
Agent's first terminal size (full width / floating panel / narrow split)	135×58 / 113×32 / 32×58	same
Never-ready Codex from "+"	tab with a silent agent, no notice	same
Never-ready Codex via "Resolve with AI"	gives up at 20.38 s, "wasn't sent", 0 bytes	20.29 s, same
Reload 0.5 s after "+"	tab kept, one agent	same
Reload 1 s after an OpenCode saved Quick Command	tab and agent kept, prompt lost (main's existing gap)	same, prompt lost
Close at +150 to +250 ms after "+"	launch cancelled silently (5/5)	agent starts and "Stop running command?" shows (4/5); see the intended difference
Time to first agent output (3 runs, median)	663.9 ms	502.3 ms

Real config files were unchanged throughout. A fresh Claude review asked only "does anything here change behaviour vs main, or exist only to fix a bug?". It found nothing on the normal path. Its edge findings are below; the Windows WSL-path case it raised is now excluded.

Automated: 144 tests across 27 named files pass, including new coverage for which launches take the host route, the background launch and the no-prompt notice. tc-gate pnpm tc:node, tc:web and tc:cli and all 22 orca-ci-checks pass; CI green at 533d54c0e4b.

Not verified: Windows and WSL machines; real (non-stand-in) agents; what a paired phone shows when the host publishes the new terminal.

Review

Fresh parity review (no shared context with the author). No user-visible difference on the normal path; nothing in the diff exists only to fix a bug. Edge cases it found, all also true of main's existing AI-button host route, labelled below.

Agent skill upstream boundary

• Not applicable.

Notes

• Intended: closing a just-launched agent tab within about a quarter second may let the agent start and show main's "Stop running command?" prompt, as main's AI-button launches do (above).
• Temporary, rare, shared with main's AI-button host route: a close during the host's first few milliseconds of workspace lookup can bring the tab back with the agent running; a launch-history record failure, host settings lagging the window's, or the workspace disappearing mid-click now show the existing "couldn't start" notice where the window would have launched. Fixed by the follow-up below.
• Temporary, kept on main's path for now: launches with a prompt, SSH workspaces, disabled agents, launches with the chat default on, and WSL-path workspaces launched from Windows. Each moves once the host matches main there.
• Follow-ups (post-migration bug fixes):
  1. First: cancel a still-pending host launch silently when its tab is closed, for every host-route caller (AI buttons included). This removes the intended difference above and the close race.
  2. The terminal-choice-at-click and launch-record-failure handling that the earlier version of this PR carried.
• Compatibility: no wire, host or mobile-facing change; the desktop calls its own host with an existing request shape.

Author: @BrennanKB5

Checklist

• This PR is small and focused (renderer routing only)
• I explained what changed and why
• Before/after screenshots attached
• Self-reviewed for correctness, security, and performance
• Cross-platform, SSH/remote, and folder-workspace impact considered
• Typecheck, named tests, static checks and CI pass

[brennanb2025]

Review, readiness and QA summary (head 34800ca578f, on #26364 5e435066d0a)

Problem. New-tab agent launches ("+", Quick Launch, floating panel, saved agent Quick Commands, dashboard, typed prompts) were started by the window's own startup queue, while the AI buttons were started by the host. Two launch owners meant two sets of rules, and fixes landed in only one.

User-facing change. Those launches now start through the host on local and SSH workspaces. You get the same tab, group, working directory, agent arguments and prompt bytes as before. The agent starts ~100 ms sooner, and the tab appears just as fast. A tab you close while it is still starting stays closed.

Fixed during review (each confirmed by a test that fails without the fix):

• A pending tab could reappear after you closed it.
• A terminal click could turn into a chat if the chat setting changed while the launch was waiting.
• Background launches lost their background presentation.
• SSH launches typed the agent command after a flat 50 ms instead of waiting for the remote shell like main's pane (fix(terminal): wait for shell-ready before every SSH startup command #12963). Now every agent.launch/agent.launchReplay into SSH uses main's delivery mode, including the AI buttons, CLI and phone launches.
• Clicking a saved Quick Command on a not-yet-connected SSH host failed with "Couldn't confirm the agent started." It now connects first, as on main.
• A failure to write the launch-history record blocked "+". The desktop's own launch now starts unrecorded and logs the failure quietly.
• A disabled agent's saved Quick Command was refused. It launches again, as on main.
• A refused launch with no prompt showed an empty "Copy prompt" action.
• Also removed: a capacity fallback that main's fix(native-chat): never refuse a user's write because the retry record is full #26543 made unreachable, and leftover dead code.

Deferred (not regressions):

• Clicking "+" on a not-yet-connected SSH workspace stays on main's existing path. This is temporary until the host can own the connect and passphrase flow.
• AI-button launches with follow-up actions, and phone/CLI launches, still refuse when the launch-history record can't be written. Their retries and follow-ups depend on that record.
• If that record fails and the terminal then also fails to start, the tab can show a plain shell with no message. This needs two failures at once.
• Pre-existing on main and unchanged here: re-selecting an already-active, already-read disconnected SSH workspace doesn't reconnect. The submit-after-ready pasted-prompt host route has no not-connected check.
• Nits: comment wording, a pass-through helper kept for test mocking.

Verified:

• Live QA used hidden, isolated macOS builds with stand-in agents, main 81fd59dab3e vs this PR, same steps on both:
  • "+", Quick Launch (click and Enter), the floating panel's "+" and shortcut, and a saved Quick Command prompt (non-ASCII marker arrived once) all match main.
  • Closing a pending tab: same as main.
  • Timing, 10 runs per side: tab visible within noise of main; first agent output ~100 ms sooner (p≈0.001).
  • SSH on a throwaway Linux container: "+", Quick Launch and Quick Command, a 2 s slow login shell, and a Quick Command clicked while the host was disconnected all match main.
  • Real config files were unchanged throughout.
• Code checks:
  • A full readiness checklist (SSH/network, crash/retry, security, performance, functional, compatibility, cross-platform, organisation) and adversarial review rounds found no open P0/P1/P2.
  • tc-gate pnpm tc:node/tc:web, 1110/1111 named tests (one 1 ms timing flake in an untouched file, passes alone), and 22/22 orca-ci-checks all pass. CI is green.

Not verified:

• Windows and WSL machines.
• Real (non-stand-in) agents.
• Launching into a workspace you are not viewing at click time: the history shortcut is ignored while the menu is open, on main too.
• The dashboard spawn and a fresh unsent draft: no on-screen control produces either today.

[brennanb2025]

Restack and re-QA on the final base (head 849eb625e43)

What changed: merged #26364's new head fac392b7af3. Four small conflicts were resolved keeping both sides. The terminal choice made at the click still keeps a desktop launch in a terminal, now next to the base's own internal terminal-only flag. The dead capacity fallback is confirmed gone: it is absent at the old head, at the new head and on main.

Checks:

• tc-gate pnpm tc:node, tc:web and tc:cli pass.
• 1459/1459 tests pass across 85 named files.
• orca-ci-checks passes 22/22.
• CI is green at 849eb625e43.

Live QA, main 7b1242ba944 (the merge-base) vs this PR. Hidden isolated builds, stand-in agents, the same steps on both.

row	main	this PR
"+" menu, Quick Launch (click and Enter), floating "+" and shortcut	PASS	PASS
Saved Quick Command prompt, marker once in argv, nothing extra typed	PASS	PASS
SSH container: connect, "+", Quick Launch, Quick Command (one remote agent per click, prompt once)	PASS	PASS
Close right after clicking: tab stays closed	PASS	PASS (see the close prompt below)
Never-ready Codex ("Resolve with AI"): gives up, "wasn't sent", 0 bytes typed	20.25 s	20.14 s, PASS
Never-ready OpenCode saved Quick Command: blind paste with Enter after the 20 s wait (main's existing fallback)	6/6	6/6
Time to first agent output (3 runs, median)	254.6 ms	134.4 ms
Tab visible (median)	47.6 ms	46.2 ms

One user-visible difference, intended. The host now creates the new tab's terminal before the tab appears. Main's existing "Stop running command?" prompt therefore applies to every close of a just-launched agent tab. On main, a close within about 0.2 s of the click was silent because the tab had no terminal yet. After "Stop and Close" the tab closes, as before.

An earlier OpenCode give-up, explained. In the first OpenCode runs, this PR gave up once in 6 tries while main pasted. The stand-in's process was named node, so only the slowest readiness evidence could match. With a stand-in whose process is named opencode, both builds pasted 6 of 6 at the same time.

Not verified:

• Windows and WSL machines.
• Real (non-stand-in) agents.
• The dashboard spawn and a fresh unsent draft: no on-screen control produces them.
• Launching into a workspace you aren't viewing.
• The slow SSH login shell and the disconnected-host Quick Command: those passed on the previous base, but weren't rerun on this head.

Follow-up (phase 2): the click's terminal choice could use the host's existing internal terminal-only flag instead of reading the prompt shape.

Author: @BrennanKB5

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Repository UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: 5c057dd4-4263-47c7-8866-11847b6a594e

---

📥 Commits

Reviewing files that changed from the base of the PR and between 8848ca9 and 533d54c.

---

📒 Files selected for processing (13)

• src/renderer/src/components/dashboard/launch-dashboard-agent.test.ts
• src/renderer/src/components/dashboard/launch-dashboard-agent.ts
• src/renderer/src/components/floating-terminal/FloatingTerminalWindowControls.test.tsx
• src/renderer/src/components/floating-terminal/FloatingTerminalWindowControls.tsx
• src/renderer/src/components/tab-bar/QuickLaunchButton.tsx
• src/renderer/src/components/tab-bar/use-tab-bar-create-menu-controller.ts
• src/renderer/src/components/use-terminal-create-actions.ts
• src/renderer/src/lib/agent-launch-through-host.test.ts
• src/renderer/src/lib/agent-launch-through-host.ts
• src/renderer/src/lib/launch-agent-fresh-new-tab-host-route.test.ts
• src/renderer/src/lib/launch-agent-in-new-tab-fresh-host.test.ts
• src/renderer/src/lib/launch-agent-in-new-tab.ts
• src/renderer/src/lib/launch-agent-new-tab-host-route.ts

---

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 6 remain after this review.

---

---

📝 Walkthrough

Walkthrough

Fresh-tab launch requests can use the host route when the request and runtime conditions match. The host launch path supports background presentation and can create a tab without activating it. Dashboard, floating terminal, tab-bar, and terminal-create launch callers now request fresh tabs. Tests cover route selection, launch results, activation behavior, and fresh-tab launch outcomes.

---

Priority: ➖ Normal

Merge Risk: ⚪ Minimal · up to 533d5

The reviewed fresh-tab launch changes have no established issue requiring resolution before merge.

Pre-merge checks | 3 | 2

❌ Failed checks (2 warnings)

Check name	Status	Explanation	Resolution
Docstring Coverage		Docstring coverage is 37.50% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 16 functions across 13 files.	Write docstrings for the functions missing them to satisfy the coverage threshold.
Description check		The description is detailed and covers the change, rationale, testing, visual proof, compatibility, risks, and checklist. However, the Linked Issue section does not include an actual issue link or iss…	Add the actual linked issue reference, such as Fixes #26489, in the Linked Issue section.

✅ Passed checks (3 passed)

Check name	Status	Explanation
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.
Title check		The title clearly identifies the main change: routing plain new-tab agent launches through the host's existing agent.launch path.

---

Full details: Description check

Explanation

The description is detailed and covers the change, rationale, testing, visual proof, compatibility, risks, and checklist. However, the Linked Issue section does not include an actual issue link or issue number as required by the template.

---

---

• Fix all pre-merge checks with AI

✨ Finishing Touches 💡 1

📝 Generate docstrings 💡

• Commit to this branch
• Create a new PR

---

---

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

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

• X
• Mastodon
• Reddit
• LinkedIn

---

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

[brennanb2025]

Parity rebuild (head 533d54c0e4b, on main 1a2ccb856e2)

What happened: following Brennan's "just parity for the migration to agent.launch, then bug fixes after", this PR was rebuilt from scratch on main. It's now a renderer-only routing change, +65 production lines. Plain no-prompt new tabs ("+", Quick Launch, floating panel, ⌘⌥T, dashboard) use the host route main already uses for the AI buttons, and only where that route matches main's own launch. #26364 is closed as no longer needed, and #26168/#26173 are being closed. The old heads are kept for reference.

Checks: tc-gate pnpm tc:node, tc:web and tc:cli pass; 144/144 tests across 27 named files; orca-ci-checks 22/22; CI green.

Review: a fresh Claude parity review found no user-visible difference on the normal path and nothing that exists only as a bug fix. I acted on the one actionable edge it found: Windows WSL-path workspaces now stay on main's path.

Live QA, main 1a2ccb856e2 vs this PR (hidden builds, stand-in agents):

Row	Result
"+", Quick Launch, floating "+" and shortcut, ⌘⌥T	PASS, same as main
Saved Quick Command prompt	PASS, byte-identical
SSH	PASS, same as main
First terminal size	PASS, identical
Never-ready Codex (both routes)	PASS, same give-up time and notice
Reload mid-launch	PASS, same as main, including main's lost OpenCode Quick Command prompt
Close within about a quarter second of clicking	DIFFERS: the agent may start and main's "Stop running command?" appears, as main's AI-button launches do today. Labelled intended. Silent cancel for every host-route caller is the first follow-up fix
Time to first output	502 ms vs main 664 ms

Not verified: Windows/WSL machines, real agents, paired-phone view.

Author: @BrennanKB5