Summary
The Electron review-workflow composer can feel sluggish, and provider selections can appear not to apply reliably. A representative case is changing the Coder provider from Claude Code to Codex in the Review until clean workflow.
Reproduction
- Launch the Electron application.
- Open New Workflow.
- Choose Review until clean.
- Change the Coder Provider from Claude Code to Codex.
- Observe the UI while the provider setup status is checked.
Observed behaviour
The controlled select handler receives the new provider value, but the composer can repeatedly re-run provider setup checks while runtime state snapshots are being broadcast. This produces unnecessary work and can make the UI feel sluggish or make a selection appear to be overwritten or delayed.
Root cause
The provider-check effect depended on the object-valued session context. Provider setup status updates mutate and broadcast runtime state, and the renderer replaces its runtime snapshot with a new object. That changes session context identity even when the effective provider and workspace inputs are unchanged, so the effect runs again.
Each run can clone or project runtime state and perform provider setup and model-catalogue work. The resulting status update causes another runtime snapshot, creating a feedback loop.
Acceptance criteria
- Changing a workflow provider is reflected by the rendered select immediately.
- Provider checks re-run when their meaningful inputs change, including provider selection or workspace.
- Unrelated runtime snapshot identity changes do not re-run the provider check.
- The review-workflow composer remains responsive during provider status updates.
- Existing provider validation behaviour is preserved.
Validation
- Electron TypeScript/build checks
- Electron acceptance artefact checks
- Lint
- Focused review-workflow runtime and graph tests
- Manual Electron smoke test: opened Review until clean, changed Coder from Claude Code to Codex, and confirmed it remained Codex after 2.5 seconds.
Summary
The Electron review-workflow composer can feel sluggish, and provider selections can appear not to apply reliably. A representative case is changing the Coder provider from Claude Code to Codex in the Review until clean workflow.
Reproduction
Observed behaviour
The controlled select handler receives the new provider value, but the composer can repeatedly re-run provider setup checks while runtime state snapshots are being broadcast. This produces unnecessary work and can make the UI feel sluggish or make a selection appear to be overwritten or delayed.
Root cause
The provider-check effect depended on the object-valued session context. Provider setup status updates mutate and broadcast runtime state, and the renderer replaces its runtime snapshot with a new object. That changes session context identity even when the effective provider and workspace inputs are unchanged, so the effect runs again.
Each run can clone or project runtime state and perform provider setup and model-catalogue work. The resulting status update causes another runtime snapshot, creating a feedback loop.
Acceptance criteria
Validation