[nwparker]

	Files	Added	Deleted	Net
Test	2	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​47	0	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​47
Prod	9	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​25	$\color{#cf222e}{\Huge{\mathbf{−}}}$​5	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​20

ELI5

orca terminal create --command "omp --thinking high" is an omp pane, but Orca only recognised the exact bare command omp. With flags the pane had no agent, so terminal wait --for tui-idle used the generic no-agent rule and returned "ready" a few seconds in, before omp had drawn anything. A prompt sent then got lost. Now Orca reads the agent from the launch command's executable, so flagged launches wait like bare ones.

Root cause

• resolveAgentTerminalCreateOptions (src/main/runtime/runtime-agent-terminal-startup.ts) only plans an agent through resolveBareAgentLaunchCommand, which needs an exact match. That's intentional: flagged commands stay user-authored shell and are never rewritten. But it means pty.launchAgent stays null.
• getPaneAgentForTuiIdle (src/main/runtime/construction/runtime-identity-state.ts) reads launchAgent ?? foregroundAgent. Until a foreground-process read lands, a flagged launch has neither, so tui-idle goes down the agent-null lane and the published agentIdentity is null.

What changed

• Built on @ggbdpq's fix(runtime): resolve the pane agent from flagged --command launches #25320 (their commit is kept as is), rebased onto the split runtime modules.
• At create and split time, a runtime-spawned pane records launchCommandAgent: the TUI agent its --command names. It's resolved once with the existing launch-intent recognizer recognizeAgentLaunchCommand, which keeps the headless/one-shot filter, so claude -p … still resolves to null (codex exec … resolves to codex while it runs, matching what the foreground-process read already reports).
• It's a fallback only. tui-idle ranking uses launchAgent ?? foregroundAgent ?? launchCommandAgent. Published identity passes launchAgent ?? launchCommandAgent into the existing resolver, where hook and process evidence still rank above it.
• Retiring launch authority (agent exit / 133;D) clears it, the same way it clears launchAgent.
• Spawn args, managed-launch rewriting and readiness rules are unchanged. Adopted and restored panes have no seed and behave as before.
• Changes in the follow-up commit compared with fix(runtime): resolve the pane agent from flagged --command launches #25320:
  • It stores the resolved agent instead of the raw command line. Reads don't re-parse, and non-agent --command panes such as pnpm dev seed nothing, so they never go through launch-authority retirement.
  • It drops a cast-based test hook and a redundant resolver unit file.
  • It adds the field missing from a fixture.

Verification (real CLI, dev Orca built from this branch, isolated userData)

I used the issue's repro script with omp 18.10.3, through a PATH shim that adds an 8s cold-start delay. On this machine omp draws in about 0.5s, so without the delay the race never shows. The issue reported 13–21s.

--command	origin/main	this branch
omp --thinking high	tui-idle after 4.1s, agentIdentity: null, 1 screen line, prompt left unsubmitted in the composer, no reply (2/2)	tui-idle after 8.7–8.8s, agentIdentity: "omp", 13 lines, pong received (2/2)
omp --approval-mode yolo	—	8.4s, omp, pong
omp (bare)	8.4s, omp, pong	8.4s, omp, pong

• omp --version (exits right away): agentIdentity goes back to null after exit.
• pnpm tc:node passes.
• The new runtime spec fails without the fix (expected null to be 'omp').
• pnpm test src/main/runtime/orca-runtime.test.ts: everything passes except 2 existing-folder import tests. Those fail identically on origin/main (macOS /private path).
• check:code-quality:changed is clean.

Risk

Low. The change is identity-only and doesn't change the wire shape: agentIdentity gains values it was already typed for. SSH and remote runtime spawns go through the same runtime create path. Mobile reads the same published identity. Windows is covered because the recognizer strips .exe/.cmd launcher extensions.

Known limitation, shared with bare managed launches: if the shell emits no 133;D when the agent exits (seen here with bash), the pane keeps the agent identity until the next process read or exit. This PR doesn't change that.

Fixes #25264
Supersedes #25320 (credit: @ggbdpq, original commit preserved).

[coderabbitai]

Walkthrough

Runtime-created PTYs now record a TUI agent recognized from the launch command, including commands with flags. Terminal identity resolution uses that value when other agent identity fields are absent. Launch-authority retirement clears it. Tests cover identity for a flagged omp command and its removal after the command-finished PTY event.

Priority: Normal

Severity of issue fixed: Medium

Merge Risk: Low · up to 07e15

The flagged launch path has no test protecting against an early readiness result. In the narrower case where exit signaling is absent, a pane can also continue to report the exited agent. These risks are bounded, but the readiness test would improve confidence before merge.

Pre-merge checks: 4 · 1

Failed checks: 1 warning

Check name	Status	Explanation	Resolution
Docstring Coverage		Docstring coverage is 40.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 5 functions across 11 files.	Write docstrings for the functions missing them to satisfy the coverage threshold.

Passed checks: 4 passed

Check name	Status	Explanation
Title check		The title clearly and concisely describes the main change: flagged --command agent launches now wait for the agent TUI.
Linked Issues check		Issue #25264 requires that tui-idle not report a flagged agent launch (for example omp --thinking high) idle before the TUI renders, and that agentIdentity be resolved despite trailing flags. Th…
Out of Scope Changes check		Every changed file traces to the identity-seeding objective of #25264: - Runtime-spawned create and split paths record launchCommandAgent. - The field is declared and initialized in the PTY record t…
Description check		The description is thorough and follows the template closely. It has an ELI5, a root cause, a detailed what-changed section, a why, a linked issue (Fixes #25264), a testing section with real-CLI verif…

Full details: Linked Issues check

Explanation

Issue #25264 requires that tui-idle not report a flagged agent launch (for example omp --thinking high) idle before the TUI renders, and that agentIdentity be resolved despite trailing flags. The issue offers two approaches. The PR uses the first approach.

Evidence at the reviewed head:

• runtime-agent-launch-resolution.ts adds resolveLaunchCommandPaneAgent. It uses recognizeAgentLaunchCommand and returns a TuiAgent only when the recognizer returns one. The headless and one-shot filter stays in place.
• terminal-create.ts and terminal-split-surface.ts set pty.launchCommandAgent for runtime-spawned panes. runtime-terminal-state-records.ts declares the field. pty-worktree-record.ts initializes it to null.
• runtime-identity-state.ts getPaneAgentForTuiIdle ranks launchAgent ?? foregroundAgent ?? launchCommandAgent, then applies isTuiAgent. A flagged omp launch therefore reaches the same agent-aware tui-idle lane as a bare omp launch.
• write-orchestration-pointer-pty.ts and pty-terminal-summary.ts pass launchCommandAgent as a fallback into the existing identity resolver. Hook and process evidence still rank above it.
• terminal-orchestration-authority.ts retirePtyAgentLaunchAuthority clears launchCommandAgent, so identity does not persist after launch authority retires.
• terminal-create-and-readiness.spec.ts adds tests. One test expects omp --model x to identify the pane as omp without launchAgent at spawn. Another expects the identity to clear after the command-finished PTY event.

The author reports real-CLI runs with an 8s cold-start delay. With the fix, omp --thinking high reached tui-idle after 8.7–8.8s, with agentIdentity omp and pong received (2/2). On origin/main, the same command returned after 4.1s with null identity (2/2). I did not re-run these checks. I did not inspect the full readiness code path outside getPaneAgentForTuiIdle, so the author's run results are the evidence that the readiness wait changes as described.

No coding requirement from #25264 appears unmet. The tui-idle readiness outcome for flagged launches depends on the reported runs and the shared agent-aware lane.

Full details: Out of Scope Changes check

Explanation

Every changed file traces to the identity-seeding objective of #25264:

• Runtime-spawned create and split paths record launchCommandAgent.
• The field is declared and initialized in the PTY record types.
• Tui-idle ranking and published identity read the field as a fallback.
• Launch-authority retirement clears the field.
• Identity pass-through in the summary and pointer paths uses the same field.
• The runtime-mobile first-turn fixture sets the new field to null so existing fixtures stay valid.
• The new spec covers the flagged-launch behavior.

The PR states that spawn arguments, managed-launch rewriting, readiness rules, and adopted or restored panes are unchanged. The reviewed diffs match that statement. I found no unrelated behavior change. The PR description also says non-agent --command panes seed nothing, so they do not enter launch-authority retirement. That matches the stored resolved agent described in the summary.

Full details: Description check

Explanation

The description is thorough and follows the template closely. It has an ELI5, a root cause, a detailed what-changed section, a why, a linked issue (Fixes #25264), a testing section with real-CLI verification tables and test results, a risk section, and notes on cross-platform, SSH, and mobile impact. Gaps: the Visual Proof section is absent, though the change is identity-only and a N/A with reason would have satisfied it. The Testing checkboxes are not ticked, the AI Disclosure section is blank, the Agent skill upstream boundary checkbox is not ticked, and the Checklist items are not ticked. These are non-critical for a PR of this scope.

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.}

[coderabbitai]

🧹 Nitpick comments: 1

src/main/runtime/orca-runtime-tests/terminal-creation-and-readiness.spec.ts: 1

233-256: Trivial · Maintainability & Code Quality · Quick win

Add a tui-idle wait assertion for the flagged OMP launch.

The new test checks only listTerminals() identity. It cannot detect an early waitForTerminal(..., { condition: 'tui-idle' }) result. No other flagged agent-command test combines runtime creation with this wait assertion.

Add a deterministic fake-timer test that delays the first TUI output and asserts that tui-idle resolves only after that output.

---

Review info

Run configuration

• Source mode: Auto
• Repository: Unavailable
• Branch: Unavailable
• File: No configuration file from this repository applied
• Commit: Unavailable
• Layers: Repository UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: b9d05c22-dbdc-4efc-aac5-80e167bc5313

Commits

Reviewing files that changed from the base of the PR and between f9df692 and 07e15be.

Files selected for processing: 11

• src/main/runtime/construction/runtime-identity-state.ts
• src/main/runtime/orca-runtime-tests/terminal-creation-and-readiness.spec.ts
• src/main/runtime/orchestration/terminal-authority/write-orchestration-pointer-pty.ts
• src/main/runtime/runtime-agent-launch-resolution.ts
• src/main/runtime/runtime-mobile-agent-status-first-turn.test.ts
• src/main/runtime/runtime-terminal-state-records.ts
• src/main/runtime/terminal/identity/pty-worktree-record.ts
• src/main/runtime/terminal/launch/terminal-create.ts
• src/main/runtime/terminal/launch/terminal-split-surface.ts
• src/main/runtime/terminal/output/terminal-orchestration-authority.ts
• src/main/runtime/terminal/query/pty-terminal-summary.ts

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