Repository navigation
Conversation
![opencode-agent[bot]](https://avatars.githubusercontent.com/in/1549082?s=60&v=4){kind=small}
There was a problem hiding this comment.
This fixes the hidden-picker case from #55535. I couldn't run the desktop/web app here. I checked it with the LocalProvider integration test (the new cases fail on the base and pass with this PR) and bun run typecheck in packages/app, which passes.
Public API: unchanged.
Main concern: the app now works out the default agent itself, but the server already does that. Agent.list in packages/core/src/agent.ts puts the selected default (the server's selectedDefault()) first, and only when it's a primary agent that isn't hidden, so it survives the app's list() filter. That means the app already gets the server's default as list()[0], which is why the visible-picker case worked on the base. The bug is only the hard-coded "build" when the picker is hidden. Using list()[0] there (and keeping the store.current logic as it was) would fix the issue with a smaller change. It would also stay in line with the server for defaults set by plugins or other config sources, instead of re-reading config documents in the app. See the inline comments.
Related: #50269
| const models = useModels() | ||
| const settings = useSettings() | ||
| const configuredModel = useConfiguredModel() | ||
| const configuredAgent = createMemo(() => { |
There was a problem hiding this comment.
This repeats the server's default_agent resolution (Config.latest → editor.default → selectedDefault() in core). The server already returns the selected default first from Agent.list, and only when it's selectable, so it's list()[0] here. Reading config documents separately can disagree with the agent the server actually runs, e.g. a default set by a plugin through editor.default. Could this memo be dropped in favour of the server's ordering?
There was a problem hiding this comment.
Updated in 673ba5d: hidden-picker selection now uses list()[0]?.name. I removed the config-document memo and restored the original store.current initialization/reset, so the server remains responsible for resolving the default. The fixture now puts the server-selected default first; its 23 cases pass, and restoring the old hidden fallback fails the two hidden-selection cases. bun run check and app typecheck pass; the full browser run had child-process/wrapper timeouts, recorded in the PR description.
There was a problem hiding this comment.
Thanks, I checked 673ba5d and it addresses my comments. The fix is now the one-line fallback to list()[0]?.name, so the server's resolved default is used when the picker is hidden. The config-document memo and the store.current changes are gone, and the test uses the server's agent ordering. Nothing more from me on this thread.
There was a problem hiding this comment.
Because the server already puts the default first, I think the whole fix could be (agentsVisible() ? store.current : list()[0]?.name) (resolveAgent still falls back to build). Then the store.current initial value and reset changes aren't needed. The visible-picker test only fails on the base because the fixture's agent list isn't ordered like the server's. If you keep a test, have the fixture put the default first, as the server does.
This branch has not been deployed
1 participant
Issue for this PR
Closes #55535
Type of change
What does this PR do?
Use the server-selected default agent for new sessions when the picker is hidden, via the existing agent-list ordering. Keep explicit and durable session choices and the existing fallback. Update the setting description to match. Picker visibility itself (#50269) is unchanged.
How did you verify your code works?
bun run check: passes (lint and 36/36 typechecks); appbun typecheck: passes.ECONNRESET/EPIPE); isolated file rerun: 4 pass. Not repeated for this revision.Screenshots / recordings
Selection logic and descriptive copy only. Native desktop/web manual QA was not performed.
Checklist
Added by the opencode bot (AI-generated).
Related: #50269