fix(desktop): reuse existing window for recipe deep links - #9289

I merged origin/main into this branch and fixed the merge conflicts.

During conflict resolution, I also fixed a bug that Codex flagged: the IPC payload was sending the full goose://recipe?config=... URL as recipeDeeplink, but the renderer's createSession → decodeRecipe path expects just the base64 config string (matching the cold-start path which passes deeplinkData?.config). This would have caused recipe decoding to fail at runtime when reusing an existing window.

The fix: recipeDeeplink: url → recipeDeeplink: deeplinkData?.config in the IPC send.

Items for human reviewer to check:

• recipeParameters and scheduledJobId are sent in the IPC payload but not consumed by the renderer handler. In the cold-start path, recipeParameters is read from appConfig by BaseChat.tsx for the ParameterInputModal. The IPC path doesn't thread these through, so parameterized recipes opened via deep link in an existing window won't get their URL query string parameter overrides. Worth deciding if this needs addressing.
• The existingWindows[existingWindows.length - 1] ?? existingWindows[0] fallback is redundant (if the array is non-empty, the last element is always defined, and if it's length 1, last === first). Minor nit.

can you look at the codex comments

Thanks @DOsinga, your recipeDeeplink: deeplinkData?.config fix is correct.

On the two Codex items:

P2 — recipeParameters not threaded. Will plumb them through AppEvents.ADD_ACTIVE_SESSION so BaseChat can read them on the warm-launch path (cold path keeps using window.appConfig).

P1 — IPC race when handleProtocolUrl spawns a new window. Will cache the payload in a pendingRecipeDeeplink module slot and replay it on reactReady, matching the existing pendingDeepLink pattern.

Pushing both shortly.

Sorry for going dark on this. Both fixes are in commit de72a03d, pushed 2026-05-19:

• Codex P2 (recipeParameters not threaded): I used a per-session module store at ui/desktop/src/utils/recipeParametersStore.ts, populated on the warm-launch IPC path in App.tsx and read by ParameterInputModal via BaseChat.tsx. Avoids touching the ADD_ACTIVE_SESSION event type. scheduledJobId stays in the IPC payload alongside.
• Codex P1 (IPC race): Reused the existing pendingDeepLinks map + react-ready handler in main.ts rather than adding a dedicated cache slot. Matches how extension and sessions deeplinks already replay.

Files touched: main.ts, App.tsx, BaseChat.tsx, plus the new recipeParametersStore.ts. No local Electron-loop test run (deps too heavy to bootstrap quickly), so worth a spot-check on the warm-window deep-link path before merging. Happy to follow up on anything that looks off.

This pull request has been automatically marked as stale because it has not had recent activity for 23 days.

What happens next?

• If no further activity occurs, this PR will be automatically closed in 7 days
• To keep this PR active, simply add a comment, push new commits, or add the keep-open label
• If you believe this PR was marked as stale in error, please comment and we'll review it

Thank you for your contribution! 🚀

Merged latest main into this branch and resolved the conflicts. Heads up: this needed more than a mechanical merge, because main has moved on since May.

What changed while this PR sat: the recipe-parameter machinery this PR built on was refactored away on main. BaseChat.tsx no longer renders ParameterInputModal, and recipe parameters now flow through an ACP request (requestAcpRecipeParams) that previously only read the global window.appConfig.recipeParameters (fixed at preload).

How I resolved it:

• Kept the core of the PR — the three protocol entry points (second-instance, processProtocolUrl, open-url) plus the react-ready pending-deeplink path now all route through the single openRecipeDeeplink helper and reuse the focused window. This is the Open new links in same window, not new window #9143 fix and still works.
• Dropped the now-obsolete ParameterInputModal/recipeParametersStore plumbing in BaseChat.tsx (that code no longer exists on main).
• To avoid a regression where a warm-launched parameterized recipe would lose its query-param values, I bridged your per-session recipeParametersStore into the new ACP flow: requestAcpRecipeParams now does takeRecipeParametersForSession(sessionId) ?? configuredParameterValues().

Verified locally: typecheck ✓, lint ✓, all UI tests pass (including the recipeParamRequests test).

Could you sanity-check a parameterized deep link on a warm window — i.e. with Goose already running, trigger goose://recipe/...?someParam=value and confirm the parameter comes through pre-filled? The unparameterized window-reuse path is the main fix; the parameterized path is the bit I adapted to the new architecture and would value a second pair of eyes on.

On the warm-window path the recipe param field opens blank, because the param store is written after the read that consumes it.

Ordering:

1. handleOpenRecipeDeeplink awaits createSession(...), then calls setRecipeParametersForSession(newSession.id, ...) only once that promise resolves.
2. createSession drives session/new, and the server asks for params inside that call before it responds: handle_new_session -> configure_new_session -> render_recipe_for_session (crates/goose/src/acp/server/new_session.rs:110) -> request_recipe_params (crates/goose/src/acp/server/recipe/mod.rs:386).
3. That request reaches the renderer at requestAcpRecipeParams, which reads takeRecipeParametersForSession(request.sessionId) ?? configuredParameterValues(). The store is still empty at this point: setRecipeParametersForSession runs after the await, and code after an await cannot execute until session/new has resolved, which only happens once this param request has already been answered.
4. So it falls back to configuredParameterValues(), i.e. window.appConfig.recipeParameters. On a warm window that config was fixed at the window's original load and holds no recipe params, so the modal opens with empty fields.

Cold start works for the opposite reason: openRecipeDeeplink with no target window creates a fresh window via createChat with recipeParameters in appConfig, so configuredParameterValues() returns the values.

Fix: populate the store before createSession, not after. The sessionId is not known until createSession resolves, so stash the pending params in a module-level slot keyed independently (or let requestAcpRecipeParams fall back to that slot), so the request_recipe_params handler can read them synchronously when the request arrives mid-session/new.

Two smaller items in the same path:

• scheduledJobId is parsed in openRecipeDeeplink but only threaded on the cold createChat branch. The warm webContents.send('open-recipe-deeplink', ...) payload, the react-ready pending-deeplink handler, and handleOpenRecipeDeeplink's createSession call all omit it, so a scheduled job opened into an existing window loses its id.
• In the target-window selection, the ?? existingWindows[0] after existingWindows[existingWindows.length - 1] never adds a case. If the array is non-empty, [length - 1] is already defined; if it is empty, both [length - 1] and [0] are undefined and it falls through to null.

Hi @SarthakB11 Thanks for your work!

I did some testing on this branch and found that there are 2 issues with deeplink

• The "Trust and Execute" windows blinks
• For the recipe with params the parameter input form window does not disappear after submitting the form.

Would you like to fix these? Thank you!

Hi @lifeizhou-ap, thanks a lot for testing this and catching both. I pushed a fix for each and rebased onto latest main.

1. "Trust and Execute" window blinking
The recipe protocol URL was getting handled more than once per click. On macOS the open-url event can fire twice for a single deep link, and on Windows/Linux the URL arrives through both the second-instance event and the startup argv. Each delivery ran openRecipeDeeplink and created its own session, so the warning modal mounted twice and flashed. I added a short burst-dedup on the recipe path, the same guard the shared-session deep link already uses, so a repeated URL inside a 2s window is ignored.

2. Parameter form not closing after submit
On the warm path the form opened with empty fields, so pressing submit hit the required-field validation and the form stayed open. The URL values were stored under the new session id, but only after createSession resolved. The parameter request actually comes back from the server in the middle of session/new, before that id exists, so the store was still empty and the form fell back to blank values. I moved the stash into a session-less pending slot that is set before createSession, so requestAcpRecipeParams reads the values when the request arrives and the fields come through pre-filled. Submit then passes validation and the form closes.

I also dropped the dead existingWindows[0] fallback you and Douwe flagged.

Verified locally: the recipe-param unit tests pass (added two for the pre-fill and the one-shot consume), and the App and ParameterInputModal tests are green. I could not drive the full Electron window loop on my side, so a re-test of both flows would be great.

One item still open from the earlier notes: scheduledJobId is threaded only on the cold createChat path, not the warm one. Carrying it end to end needs a new field on the ACP recipe options, so I left it out here to keep the change focused. I can follow up on that separately if useful.

Thanks @DOsinga, all four done and pushed:

1. Window filter: now selects only from tracked chat windows, so the launcher and standalone windows can no longer get a recipe session.
2. Pending stash: cleared in a finally, so an unconsumed stash never outlives its deep link.
3. scheduledJobId: nothing reads it on either path today, so the warm path dropping it is not a regression. I can wire it as a follow-up if you want that supported.
4. Comments: trimmed to the ACP-timing reason.

Tests pass; a re-test of the warm launcher case would be welcome.

All handled by the follow-up commit c344d36: config sent instead of the full URL, params stashed before session creation, IPC deferred until the renderer is ready, and reuse scoped to tracked chat windows.

Hi @SarthakB11,

Thanks for the update.

I tested this again, and the issue still seems to exist:

For a recipe with params, the parameter input form window does not disappear after submitting the form.

Could you please take another look? When you update the PR again, it would also be helpful to run through the recipe params flow end-to-end to make sure the submit behavior is working as expected.

Thanks again for working on this.

Closing due to that last followup not being addressed for two weeks #9289 (comment)