feat(composer): persist Codex params per thread#380
feat(composer): persist Codex params per thread#380Dimillian merged 12 commits intoDimillian:mainfrom
Conversation
Persist model, effort, access mode, and collaboration mode selections per thread in localStorage.
|
hmmmmmmm but a new thread take which default? |
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 85b7f1d112
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| useEffect(() => { | ||
| if (!enabled) { | ||
| return; | ||
| } | ||
| if (selectionKey === lastSelectionKey.current) { | ||
| return; | ||
| } | ||
| lastSelectionKey.current = selectionKey; | ||
| setSelectedModeId(preferredModeId); |
There was a problem hiding this comment.
Preserve a valid collaboration mode on thread switch
When the per-thread selectionKey changes, this effect unconditionally replaces the current selection with preferredModeId (which is null for threads without stored overrides), so switching to such a thread clears selectedCollaborationModeId even though the mode list is already loaded and a default is available. Because no refetch runs on thread change, the selection stays null, which in turn makes useCollaborationModeSelection produce a null payload and drops collaboration-mode settings for those threads. Consider keeping the existing selection or falling back to the computed default when preferredModeId is null or not present in modes.
Useful? React with 👍 / 👎.
It seems it uses no plan-mode, last used codex model, last used effort and on-request access mode. |
|
hmmmm not sure we wants that |
|
Ok, what do you think would be best? To me, the problem is that every time I change an agent, I carry the last parameters and it can be confusing if I'm working on multiple at the same time. |
|
Hmmmm I think we should have those param in the main app settings (I think we already do, but partially?) |
|
Not sure where it fit best or if we need a new section 😆 |
|
Ok, I think it works great now, but I'd appreciate it if someone does some testing, just to make sure! |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c0281deb78
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| return; | ||
| } | ||
| lastSelectionKey.current = selectionKey; | ||
| setSelectedModeId(preferredModeId); |
There was a problem hiding this comment.
Preserve a valid collaboration mode on thread switches
When selectionKey changes, this effect unconditionally assigns preferredModeId (which is null for threads without a stored override in App.tsx) to selectedModeId. In that common case, the hook clears the existing/default mode, and because lastFetchedWorkspaceId is already set for the workspace, no refetch runs to restore a default selection; subsequent sends from that thread omit collaborationMode until the user manually reselects one.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f3f3b9bf2a
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
… modes Branch summary (Codex params + settings + collaboration modes) Settings -> Codex - Added a 'Default parameters' section that lets users pick default model, reasoning effort, and access mode. - Model options are aggregated from connected workspaces via getModelList(), de-duped by slug, and sorted by a 'latest' heuristic. - Reasoning effort options are derived from the selected model's supportedReasoningEfforts (lowercased) and default to 'medium'. - Removed any explicit 'default' option from model/effort pickers; the section context is the default. - Styled these controls like other settings cards. Thread-scoped Codex params - Persist per-thread overrides for model/effort/collaboration/access. - Keep per-thread changes from mutating the global defaults; global defaults only change in the no-thread composer. - Seed newly created threads once (avoid post-send flips) so model/effort/collab/access remain stable after the first message. Collaboration modes - On thread switch, prefer the thread override; otherwise reset to the workspace default so plan/code selections don't bleed across threads. - When sending the first message from the no-thread composer, snapshot collaboration mode and access mode and apply them to the created thread. - Validate preferredModeId on selectionKey changes: if a stored override is stale (mode removed/renamed), fall back to the workspace default instead of disabling collaboration payloads. Tests - Added a regression test for stale preferredModeId fallback in useCollaborationModes.
# Conflicts: # src/App.tsx
|
@Dimillian I was about to fix the conflicts! We good? |
Yes finishing touches |

Persist model, effort, access mode, and collaboration mode selections per thread in localStorage.