Repository navigation
fix(pty): Pi and OMP agents started from the window in WSL report status from their first launch - #29780
Conversation
…ike host spawns A Pi or OMP agent started from the window inside WSL, with the terminal daemon on, could start before the distro's hook relay was up. It then reported no working/idle status for that session. Host starts and local-provider starts already waited (#21721); the window's daemon path was the one left out. The shared host-env step now always runs the wait on the daemon spawns it builds, so the lane input that skipped it for window starts is gone. The wait is a no-op for anything but an explicit Pi/OMP launch in WSL.
…window-daemon-wsl-readiness
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Priority: ⬇️ Low Merge Risk: ⚪ Minimal · up to
|
| Check name | Status | Explanation | Resolution |
|---|---|---|---|
| Docstring Coverage |  |
Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 1 functions across 2 files. | Write docstrings for the functions missing them to satisfy the coverage threshold. |
-
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. Description check The description is complete and directly matches the implementation. It explains the user impact, mechanism, rationale, limitations, testing, review findings, and checklist status. It references the f… Title check The title clearly identifies the fix and its affected behavior: Pi and OMP agents launched from the WSL window now report status on their first launch. Full details: Description check
-
Explanation
The description is complete and directly matches the implementation. It explains the user impact, mechanism, rationale, limitations, testing, review findings, and checklist status. It references the follow-up issue
#29297, although it does not use the template's exact “Fixes #” form.
-
- 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.
Comment @coderabbitai help to get the list of available commands.
|
Pi and OMP terminals started from the window inside WSL could beat the guest status relay because that daemon launch path skipped preparation that the other paths already awaited. The shared environment builder now applies the same bounded preparation to both callers, so a relay that becomes ready within ten seconds is wired before the first agent process starts. A failed or slow relay still lets the agent launch, with potentially degraded status. The architecture challenger and independent correctness review found no proven defects, and no production fixes were needed during the loop. The kept differences are intended: preparation is best-effort, global hooks-off returns promptly, and individual-agent opt-out or inconsistent agent/command metadata still follow the existing helper's classification. Verification: six named suites passed again after the once-only main merge (157 tests); the retained reviewer found no defects in that integration delta. The final source readiness scan found no additional candidates. Full PR Checks passed on For Brennan's review
Human judgment: the shared preparation step retains the existing ten-second, nonfatal status-setup tradeoff. The separate degraded daemon fallback missing the full host environment remains tracked in STA-10858. |
ELI5
A Pi or OMP agent started from the Orca window inside WSL could run without working/idle status because its terminal started before the WSL status relay was ready. The window now uses the same preparation already used by the other terminal launch paths.
What Changed
The shared daemon environment builder now waits for Pi/OMP guest preparation before reading the endpoint and extension paths. The caller can no longer skip that preparation merely because a window requested the terminal. Local-provider and adopted terminals return before this step, so they gain no duplicate wait.
When preparation finishes within the existing ten-second limit, the first launch receives the guest status endpoint and extensions. If preparation fails or times out, the agent still starts and status may remain degraded. A cold launch can therefore take up to ten seconds longer; tab order, selection, setup and notices are unchanged.
Why
The earlier consolidation in #29297 preserved the window/host difference as a temporary boolean. Removing that input fixes the omitted launch path at the existing shared boundary. Turning the synchronous environment builder into another asynchronous layer would add changes without another launch path to cover.
This follows the common pattern of preparing terminal integration before process creation. The intended difference is that optional status preparation remains bounded and nonfatal.
Linked Issue
Follow-up to #29297 in the terminal launch convergence work. The separate issue where a daemon startup fallback lacks the entire host environment remains tracked in Linear STA-10858.
Visual Proof
Windows Electron comparison completed on main
79b916395150eeee2954f03c30cc1744d95f6bcfand final PR0a278751079c4c316e1b8c4fdadb59be9e365c87. Native launch/environment parity passed; normalized recorded fields have no differences.The comparison covers Command Prompt selected through Settings, a normal + terminal, and an absolute-path stand-in launched from the window. Stand-ins verify commands/environment only. WSL endpoint/status and resume rows are blocked: the available distro uses a real Linux home that the rig cannot isolate, and suitable Pi/OMP are unavailable without installation/sign-in. No live first-launch WSL status result is claimed.
Both heads also reproduce three pre-existing failures in the hidden rig: the first default tab needs a tab switch to start, a launch-failure notice precedes the successful stand-in, and CODEX_HOME is absent from panes. No fix is included for those independent behaviors, and no real-agent success is claimed. An automatic session-search promotion appeared during PR Settings navigation; this timing difference was not established as a regression, and search was never opened.
Both rig process trees stopped and ports cleared; protected hashes were stable within each arm. A config hash changed between arms while neither rig was active; the report leaves its writer unattributed.
An earlier QA attempt was stopped after a rig isolation failure and is excluded from acceptance evidence. Final launch fixtures use absolute-path stand-ins; no real-agent success is claimed.
Testing
Review
The independent correctness review and architecture challenger found no proven defects; no production fixes were needed. The retained reviewer also checked the final main merge on 0a27875 and found no new defects.
The wait is a no-op outside WSL and for ordinary other-agent commands. Global hooks-off returns promptly. Individual Pi/OMP opt-out or inconsistent agent/command metadata still follows the existing helper's classification and may incur the bounded wait. No saved data, dependency, wire format or minimum server version changes; paired hosts retain their existing path. No mobile-facing surface touched.
Agent skill upstream boundary
Notes
Production +7/-13; tests +3/-4. No new tests, saved fields or protocol operations.
Checklist