Analyzed GitHub issue #844 for root cause and
Public
Analyzed GitHub issue #844 for root cause and
Agent
Pi
Model
GPT-5.2 Codex
Started
Jan 19, 1:19 PM
Messages51
Downloads0
Reviewed issue #844 and related comments.
UnderstandExamined all related code files in full.
UnderstandTraced code paths for model selection and session handling.
UnderstandProposed a fix approach based on root cause analysis.
Plan
Analyze GitHub issue(s): https://github.com/badlogic/pi-mono/issues/844
For each issue:
Read the issue in full, including all comments and linked issues/PRs.
For bugs:
For feature requests:
Do NOT implement unless explicitly asked. Analyze and propose only.
Preparing to view GitHub issue
>gh issue view 844 --json title,body,comments,labels,stateStarting full related code exploration
I'm preparing to search for files related to scoped models and the model to understand the bug context fully.
>lsChoosing search tool
Considering whether to use grep or ripgrep for locating the needed item.
>rg -n "scoped-models|scoped models|scopedModels|scoped_model" packagesPreparing to read key source files
I'm identifying the main files to read in full—interactive mode and scoped models selector components—to analyze the relevant code without truncation, ensuring full content retrieval despite potential file size.
>ls packages/coding-agent/src/modes/interactive/componentsReading full interactive mode
Planning multi-part file reading
The full file exceeds 50KB, so I'll read it in parts using offsets despite the general guideline against offset/limit for full reads; this approach ensures complete coverage without truncation.
Identifying key files to review
I'm targeting related files like scoped-models-selector.ts, model-selector.ts, agent-session.ts, settings-manager, model registry, and core/model-resolver for reading, focusing on functions like resolveModelScope and usage of modelRegistry in interactive-mode.
Reading model selectors and settings manager
I'm examining the scoped-models-selector, model-selector, and settings manager to understand how model persistence and enabled models interact, focusing on the scoped models and their effect on model visibility.
Identifying need for model-selector component
Reviewing settings-manager for enabled models
I'm checking the settings-manager and model-registry to understand how getEnabledModels settings are accessed and used.
Investigating model enabling and scoping
I'm checking where settings for enabled models are used to set session scopedModels, which affects /model API behavior when scopedModels is not empty. I'll search for how and when enabledModels updates scopedModels, likely around startup.
>rg -n "enabledModels|setEnabledModels|getEnabledModels|scopedModels" packages/coding-agent/srcPrioritizing main.ts review
I'm focusing on main.ts to understand how interactive scoped models persist in settings and will check core/sdk next if needed.
Analyzing model scoping and persistence
The /model endpoint uses session scoped models derived from saved enabled models in settings, causing it to show only scoped models rather than all. Persisting changes updates settings but doesn't refresh session scoped models immediately, leading to this mismatch. A fix should ensure /model shows all models or session scoped models update consistently after persistence.
Distinguishing cycling scope from model filtering
The current conflation of session scoped models for both cycling (/scoped-models) and /model filtering causes /model to wrongly limit visible models. To fix this, cycling scope from settings should remain separate from /model filtering, which should show all models unless explicitly limited by CLI --models. Adding distinct session flags for CLI scope versus cycling scope and adjusting the model selector to differentiate these will align behavior with expectations.
Identifying related model-resolver code
The scoped models persist via enabledModels in settings affecting main scopedModels, which incorrectly impacts /model instead of just cycling. I’ll review model-resolver next to clarify its role in scopes and dependencies.
Analyzing model scoping root cause
The root cause is that the /model selector relies on session scoped models created from persisted enabledModels settings, restricting the displayed list. The fix involves distinguishing scoped models by source, only restricting /model when scoped from CLI, and allowing full listing otherwise by tagging scopedModels with a source flag.
Proposing scoped models source tracking
The fix is to track the source of scoped models in the session—distinguishing CLI --models (restricting /model list) from settings-based scopes (limiting only cycling). This involves adding a scope source flag in the session, updating interactive mode and model selector to use full model list except when scoped by CLI, and adjusting hint text accordingly to avoid unintended filtering on /model.
Issue 844 analysis
Type: bug
Linked issues or PRs: none.
What happens in code
parsed.models ?? settingsManager.getEnabledModels() to build scopedModels via resolveModelScope.scopedModels, and AgentSession stores them in _scopedModels.session.scopedModels to build the candidate list in:
--models scope, so /model only shows the scoped set and shows the “Showing models from --models scope” hint.Actual root cause
The same scopedModels list is used for two different purposes:
scopedModels on startup, so /model is unintentionally filtered.Proposed fix Separate “cycling scope” from “model selector scope”.
Concise implementation approach
modelScopeSource: "cli" | "settings" | "session" | "none"isModelSelectionScoped.scopedModels:
parsed.models set to clisettings/scoped-models session-only updates set to session.cli.Affected files and changes
isModelSelectionScoped.This keeps /scoped-models as a Ctrl+P preference while preserving --models as a hard scope for /model when explicitly requested.