Repository navigation
Conversation
Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-openagent) Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>
📝 WalkthroughWalkthroughThe launch planner validates inline OpenCode startup drafts against platform limits. It embeds fitting prompts in startup commands. It uses the existing post-ready paste-and-submit path for oversized drafts and other agents. The launch flow waits up to 8 seconds for agent readiness before reporting prompt delivery. Vitest coverage verifies planning, fallback flags, readiness waiting, delivery results, and callback timing. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
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 |
Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-openagent) Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>
There was a problem hiding this comment.
🧹 Nitpick comments (1)
src/renderer/src/lib/launch-agent-in-new-tab.test.ts (1)
178-178: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winUse a deferred readiness mock.
mockWaitForAgentReady.mockResolvedValuereturns an already fulfilled promise. The test only proves thatonPromptDeliveredis not called in the same synchronous stack. It does not prove that delivery waits for readiness or exercise the inline timeout branch. Hold the promise pending, assert that delivery remains pending, then resolve it and add aready: falsecase.Also applies to: 230-253
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 5f07a0bd-7f8c-4956-9f3e-a3defe220b41
📒 Files selected for processing (2)
src/renderer/src/lib/launch-agent-in-new-tab.test.tssrc/renderer/src/lib/launch-agent-in-new-tab.ts
Greptile SummaryThis PR fixes OpenCode's continuation prompt delivery by routing normal-sized handoff prompts through OpenCode's
Confidence Score: 3/5The inline delivery tracking branch reuses a paste-path timeout mechanism that fires a misleading 'paste it once the agent is ready' toast and returns delivered: false when OpenCode takes longer than 8 s to emit readiness signals — even though the prompt was already committed to the launch command via --prompt and cannot be unsent. The plan-selection logic and the Windows fallback are clean. The concern is in the new inline tracking branch: createPasteReadinessTimeoutNotice was designed for paste delivery, where timeout genuinely means the prompt was never received. For inline --prompt delivery, a timeout only means readiness detection failed, not that the prompt was lost. Reusing it here can instruct the user to paste a prompt that OpenCode will already process on startup, potentially causing duplication. The timeout path also has no test, so this regression would not be caught before reaching users. Files Needing Attention: The new inline tracking block in launch-agent-in-new-tab.ts (lines 220–239) needs a dedicated timeout notice or a different handling strategy for the { ready: false } case to avoid the misleading toast and incorrect delivered value.
|
| Filename | Overview |
|---|---|
| src/renderer/src/lib/launch-agent-startup-prompt-plan.ts | Adds OpenCode-specific inline launch path for submit-after-ready: tries --prompt first, falls back to paste-after-ready when the command exceeds platform limits. Logic is straightforward and well-bounded by the agent check and inlineAgentDraftFitsPlatform guard. |
| src/renderer/src/lib/launch-agent-in-new-tab.ts | New inline delivery tracking branch for OpenCode reuses createPasteReadinessTimeoutNotice, which fires a misleading 'paste it once the agent is ready' toast and returns delivered: false on timeout — incorrect because the prompt is already embedded in the launch command via --prompt. |
| src/renderer/src/lib/launch-agent-in-new-tab.test.ts | New test covers the inline delivery success path; the timeout/failure path for the inline branch is not exercised. |
| src/renderer/src/lib/launch-agent-startup-prompt-plan.test.ts | New test file with clear coverage for the two key cases: fitting inline plan on Linux, and oversized prompt fallback to paste on Windows. Correct and sufficient for the plan logic. |
Flowchart
%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[launchAgentInNewTab called with submit-after-ready] --> B[planLaunchAgentStartupPrompt]
B --> C{agent === opencode?}
C -- No --> D[pasteAfterReady pasteDraftAfterLaunch = prompt]
C -- Yes --> E[buildAgentStartupPlan with --prompt flag]
E --> F{inlineAgentDraftFitsPlatform?}
F -- No / Windows oversized --> D
F -- Yes --> G[pasteDraftAfterLaunch = null startupPlan has --prompt]
G --> H[new inline tracking branch]
H --> I[createPasteReadinessTimeoutNotice]
H --> J[waitForAgentReady timeoutMs: 8000]
J --> K{ready?}
K -- true --> L[onPromptDelivered called delivered: true]
K -- false / timeout --> M[timeoutNotice.onTimeout Your prompt was not sent paste it delivered: false misleading: prompt was in --prompt flag]
D --> N[deliverLaunchPromptToAgentTab paste path]
N --> O{delivered?}
O -- true --> P[onPromptDelivered called]
O -- false --> Q[timeoutNotice.onTimeout delivered: false]
Reviews (1): Last reviewed commit: "Track inline OpenCode delivery" | Re-trigger Greptile
| if (hasPrompt && promptDelivery === 'submit-after-ready' && pasteDraftAfterLaunch === null) { | ||
| const timeoutNotice = createPasteReadinessTimeoutNotice({ | ||
| worktreeId, | ||
| tabId: tab.id, | ||
| agent, | ||
| submitted: true | ||
| }) | ||
| promptDeliveryResult = waitForAgentReady(tab.id, startupPlan.expectedProcess, { | ||
| timeoutMs: INLINE_PROMPT_DELIVERY_TIMEOUT_MS | ||
| }).then(({ ready }) => { | ||
| if (ready) { | ||
| onPromptDelivered?.() | ||
| } else { | ||
| timeoutNotice.onTimeout() | ||
| } | ||
| return { | ||
| delivered: ready, | ||
| failureNotified: !ready && timeoutNotice.wasNotified() | ||
| } | ||
| }) |
There was a problem hiding this comment.
Misleading timeout toast on inline
--prompt delivery
createPasteReadinessTimeoutNotice is reused here, but its onTimeout handler fires the message "Your prompt wasn't sent — paste it once the agent is ready." For the inline OpenCode path the prompt is already embedded in the launch command (opencode --prompt '...'), so OpenCode will process it regardless of whether waitForAgentReady detects readiness within 8 seconds. If the process simply takes longer than 8 s to emit a recognisable readiness signal (slow machine, cold start, large context), the user sees a false alarm instructing them to paste the prompt again — which would create a duplicate submission. The delivered: false value that propagates to callers is similarly incorrect: the prompt was already committed to the launch command, not paste-dependent.
A separate timeout notice that either skips the toast or uses a different message (e.g. "We couldn't confirm the agent started — check the terminal") is needed for this branch, or the delivered value should reflect that the command was issued even when readiness detection times out.
| it('tracks inline OpenCode continuation delivery until the agent is ready', async () => { | ||
| const onPromptDelivered = vi.fn() | ||
| const { launchAgentInNewTab } = await import('./launch-agent-in-new-tab') | ||
|
|
||
| const result = launchAgentInNewTab({ | ||
| agent: 'opencode', | ||
| worktreeId: 'wt-1', | ||
| prompt: 'Continue from the previous session.', | ||
| promptDelivery: 'submit-after-ready', | ||
| onPromptDelivered | ||
| }) | ||
|
|
||
| expect(result?.promptDeliveryResult).toBeDefined() | ||
| expect(onPromptDelivered).not.toHaveBeenCalled() | ||
| await expect(result?.promptDeliveryResult).resolves.toEqual({ | ||
| delivered: true, | ||
| failureNotified: false | ||
| }) | ||
| expect(mockWaitForAgentReady).toHaveBeenCalledWith('tab-1', 'opencode', { | ||
| timeoutMs: 8000 | ||
| }) | ||
| expect(onPromptDelivered).toHaveBeenCalledOnce() | ||
| }) |
There was a problem hiding this comment.
Timeout path for inline delivery has no test coverage
The new test covers only the happy path (waitForAgentReady resolves { ready: true }). There is no test for waitForAgentReady resolving { ready: false, reason: 'timeout' } on the inline delivery branch. Given the P1 concern above (misleading toast + incorrect delivered value), this gap also means the incorrect behaviour would not be caught by the test suite until a user reports it.
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
|
Superseded by #11859. The replacement keeps transcript-derived context on the sanitized post-ready transport and fixes synthetic OpenCode SQLite transcript paths. |
Summary
--promptlaunch path for normal Continue in New Session handoffsWhy
The continuation flow always forced OpenCode through the readiness-gated paste path. The installed Orca build still uses that path, so context can fail to reach the new session. OpenCode supports
--prompt, which avoids the startup paste race for normal-sized handoff prompts. Inline launches now wait for the launched process to become ready before reporting delivery success.Validation
pnpm run typecheck:weboxlint --deny-warningsopencode --helpconfirms--promptsupportThe full suite previously had 10 unrelated environment/pre-existing failures; details are documented in the task handoff.