feat(agent-manager): add mode selection for CLI sessions #5211
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
🦋 Changeset detectedLatest commit: 649196f The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Contributor
Code Review SummaryStatus: No New Issues Found | Recommendation: Address existing feedback before merge OverviewThis PR adds mode selection to Agent Manager for CLI sessions. The implementation is well-structured with:
Previous Review FeedbackThe existing inline comments from previous reviewers cover the main areas for improvement:
Files Reviewed (35 files)Core Changes:
Agent Manager UI:
Styling:
i18n (20 locale files):
Automated review by Kilo Code |
iscekic
reviewed
Jan 19, 2026
webview-ui/src/kilocode/agent-manager/components/SessionModeSelector.tsx
Outdated
Show resolved
Hide resolved
Addresses PR review comment about duplication between ModeSelector and SessionModeSelector. The shared hook builds mode dropdown options from available modes, with optional translation support for the organization modes header.
- Add mode to CreateSessionOptions interface in AgentRegistry - Store mode when creating sessions with DEFAULT_MODE_SLUG fallback - Add mode to PendingProcessInfo interface in CliProcessHandler - Pass mode through all session creation paths - Remove global effectiveModeSlugAtom fallback in SessionModeSelector - Each session now stores and uses its own mode independently This fixes the bug where changing the mode in the new session form would affect the displayed mode in all running sessions.
Collaborator
Author
|
@iscekic thanks for the review. I addressed the comments. Additionally the implementation still had a bug that would lead into multiple sessions sharing the same mode change. That's also fixed now. |
… pass mode to createSession
…n modes Organization modes were failing with 'KiloCode token + baseUrl is required to fetch models' because the agent process didn't have access to the mode configurations. This fix: 1. Adds customModes parameter to RuntimeProcessHandler.buildAgentConfig() 2. Adds customModes parameter to RuntimeProcessHandler.spawnProcess() 3. Updates AgentManagerProvider.spawnAgentWithCommonSetup() to fetch custom modes (including organization modes) and pass them to the agent process Now the agent process receives all custom mode configurations at startup, eliminating the need to fetch them from the API during runtime.
The extension expects { type: 'mode', text: mode } webview messages,
not { type: 'setMode', mode }. Updated setSessionMode() to send the
correct message format via IPC.
… modes
The CustomModesManager.getCustomModes() method reads organization modes from
globalState.get('customModes'). In agent processes, customModes were only
stored in the currentState but not in globalState, causing organization modes
to fail with 'KiloCode token + baseUrl is required to fetch models' error.
This fix stores customModes in globalState when the ExtensionHost initializes,
ensuring CustomModesManager can find organization modes in agent processes.
…odeChanged callback The RuntimeProcessHandler was not detecting mode changes from state updates sent by the agent process. This fix: - Adds sessionModes map to track current mode for each session - Detects mode changes in handleExtensionMessage when processing state updates - Calls onModeChanged callback when mode changes are detected - Cleans up sessionModes when sessions are terminated
…gging Added logging to trace custom modes flow: - AgentManagerProvider: logs mode slugs and sources when fetching custom modes - RuntimeProcessHandler: logs mode and custom modes in buildAgentConfig - agent-runtime process.ts: logs custom modes received from parent - ExtensionHost: logs custom modes storage in globalState
webview-ui/src/kilocode/agent-manager/state/hooks/useAgentManagerMessages.ts
Outdated
Show resolved
Hide resolved
webview-ui/src/kilocode/agent-manager/components/SessionModeSelector.tsx
Outdated
Show resolved
Hide resolved
…dcoded 'code' The ExtensionHost was hardcoding mode to 'code' in the initial state instead of using the mode passed via options. This fix: - Adds 'mode' field to ExtensionHostOptions interface - Passes mode from ExtensionServiceOptions to ExtensionHostOptions - Uses options.mode (with 'code' fallback) in initial state - Adds logging to show the initial mode being set
Collaborator
Author
|
@iscekic I merged the IPC rewrite of the agent manager. I had to disable organizational modes for now, we ship them later. Mode selection should work fine now with this. |
- Disable organization modes temporarily (require additional API config work) - Use i18n for SessionModeSelector title - Make previousMode optional in ModeChangedMessage interface - Remove debug logging
When resuming a session, the mode was not being passed to spawnAgentWithCommonSetup, causing the agent to always start in 'code' mode regardless of the original session mode. Now the mode is properly restored from either: 1. sessionData.metadata.mode (from server) 2. session.mode (from local registry) This ensures that when a user resumes a session that was started in a custom mode (e.g., 'Brian Mode'), the agent will continue using that mode.
…esume The mode was being passed to buildAgentConfig (for the agent process) but not to registry.createSession when creating a new session entry for a resume. This caused the UI to show 'code' mode even though the agent was running in the correct mode. Now the mode is passed to both: 1. buildAgentConfig - for the agent process configuration 2. registry.createSession - for the UI session state
This was referenced Jan 22, 2026
Merged
maywzh
pushed a commit
to maywzh/kilocode
that referenced
this pull request
Jan 25, 2026
* feat(agent-manager): add mode selection for CLI sessions
* refactor: extract shared useModeOptions hook to reduce duplication
Addresses PR review comment about duplication between ModeSelector and
SessionModeSelector. The shared hook builds mode dropdown options from
available modes, with optional translation support for the organization
modes header.
* fix: move css-prefix test to src directory for Node.js environment
* fix: isolate mode state per session in Agent Manager
- Add mode to CreateSessionOptions interface in AgentRegistry
- Store mode when creating sessions with DEFAULT_MODE_SLUG fallback
- Add mode to PendingProcessInfo interface in CliProcessHandler
- Pass mode through all session creation paths
- Remove global effectiveModeSlugAtom fallback in SessionModeSelector
- Each session now stores and uses its own mode independently
This fixes the bug where changing the mode in the new session form
would affect the displayed mode in all running sessions.
* fix: add onModeChanged callback to RuntimeProcessHandlerCallbacks and pass mode to createSession
* fix(agent-manager): pass customModes to agent process for organization modes
Organization modes were failing with 'KiloCode token + baseUrl is required
to fetch models' because the agent process didn't have access to the mode
configurations. This fix:
1. Adds customModes parameter to RuntimeProcessHandler.buildAgentConfig()
2. Adds customModes parameter to RuntimeProcessHandler.spawnProcess()
3. Updates AgentManagerProvider.spawnAgentWithCommonSetup() to fetch
custom modes (including organization modes) and pass them to the
agent process
Now the agent process receives all custom mode configurations at startup,
eliminating the need to fetch them from the API during runtime.
* fix(agent-manager): fix mid-session mode switching message format
The extension expects { type: 'mode', text: mode } webview messages,
not { type: 'setMode', mode }. Updated setSessionMode() to send the
correct message format via IPC.
* fix(agent-runtime): store customModes in globalState for organization modes
The CustomModesManager.getCustomModes() method reads organization modes from
globalState.get('customModes'). In agent processes, customModes were only
stored in the currentState but not in globalState, causing organization modes
to fail with 'KiloCode token + baseUrl is required to fetch models' error.
This fix stores customModes in globalState when the ExtensionHost initializes,
ensuring CustomModesManager can find organization modes in agent processes.
* fix(agent-manager): detect mode changes in state updates and call onModeChanged callback
The RuntimeProcessHandler was not detecting mode changes from state updates
sent by the agent process. This fix:
- Adds sessionModes map to track current mode for each session
- Detects mode changes in handleExtensionMessage when processing state updates
- Calls onModeChanged callback when mode changes are detected
- Cleans up sessionModes when sessions are terminated
* chore(agent-manager): add detailed logging for organization mode debugging
Added logging to trace custom modes flow:
- AgentManagerProvider: logs mode slugs and sources when fetching custom modes
- RuntimeProcessHandler: logs mode and custom modes in buildAgentConfig
- agent-runtime process.ts: logs custom modes received from parent
- ExtensionHost: logs custom modes storage in globalState
* fix(agent-runtime): use options.mode for initial state instead of hardcoded 'code'
The ExtensionHost was hardcoding mode to 'code' in the initial state instead
of using the mode passed via options. This fix:
- Adds 'mode' field to ExtensionHostOptions interface
- Passes mode from ExtensionServiceOptions to ExtensionHostOptions
- Uses options.mode (with 'code' fallback) in initial state
- Adds logging to show the initial mode being set
* chore: add detailed logging for API configuration debugging
* fix(agent-manager): address PR review comments
- Disable organization modes temporarily (require additional API config work)
- Use i18n for SessionModeSelector title
- Make previousMode optional in ModeChangedMessage interface
- Remove debug logging
* fix(agent-manager): add portal container for dropdown scrolling
* fix(ui): add overscroll-contain to dropdown for scroll wheel support
* fix(agent-manager): add overflow-y and overscroll-behavior to mode selector content
* Fix comment
* fix(agent-manager): restore mode when resuming sessions
When resuming a session, the mode was not being passed to spawnAgentWithCommonSetup,
causing the agent to always start in 'code' mode regardless of the original session mode.
Now the mode is properly restored from either:
1. sessionData.metadata.mode (from server)
2. session.mode (from local registry)
This ensures that when a user resumes a session that was started in a custom mode
(e.g., 'Brian Mode'), the agent will continue using that mode.
* fix(agent-manager): pass mode to registry when creating session for resume
The mode was being passed to buildAgentConfig (for the agent process) but not
to registry.createSession when creating a new session entry for a resume.
This caused the UI to show 'code' mode even though the agent was running
in the correct mode.
Now the mode is passed to both:
1. buildAgentConfig - for the agent process configuration
2. registry.createSession - for the UI session state
maywzh
pushed a commit
to maywzh/kilocode
that referenced
this pull request
Jan 25, 2026
* feat(agent-manager): add mode selection for CLI sessions
* refactor: extract shared useModeOptions hook to reduce duplication
Addresses PR review comment about duplication between ModeSelector and
SessionModeSelector. The shared hook builds mode dropdown options from
available modes, with optional translation support for the organization
modes header.
* fix: move css-prefix test to src directory for Node.js environment
* fix: isolate mode state per session in Agent Manager
- Add mode to CreateSessionOptions interface in AgentRegistry
- Store mode when creating sessions with DEFAULT_MODE_SLUG fallback
- Add mode to PendingProcessInfo interface in CliProcessHandler
- Pass mode through all session creation paths
- Remove global effectiveModeSlugAtom fallback in SessionModeSelector
- Each session now stores and uses its own mode independently
This fixes the bug where changing the mode in the new session form
would affect the displayed mode in all running sessions.
* fix: add onModeChanged callback to RuntimeProcessHandlerCallbacks and pass mode to createSession
* fix(agent-manager): pass customModes to agent process for organization modes
Organization modes were failing with 'KiloCode token + baseUrl is required
to fetch models' because the agent process didn't have access to the mode
configurations. This fix:
1. Adds customModes parameter to RuntimeProcessHandler.buildAgentConfig()
2. Adds customModes parameter to RuntimeProcessHandler.spawnProcess()
3. Updates AgentManagerProvider.spawnAgentWithCommonSetup() to fetch
custom modes (including organization modes) and pass them to the
agent process
Now the agent process receives all custom mode configurations at startup,
eliminating the need to fetch them from the API during runtime.
* fix(agent-manager): fix mid-session mode switching message format
The extension expects { type: 'mode', text: mode } webview messages,
not { type: 'setMode', mode }. Updated setSessionMode() to send the
correct message format via IPC.
* fix(agent-runtime): store customModes in globalState for organization modes
The CustomModesManager.getCustomModes() method reads organization modes from
globalState.get('customModes'). In agent processes, customModes were only
stored in the currentState but not in globalState, causing organization modes
to fail with 'KiloCode token + baseUrl is required to fetch models' error.
This fix stores customModes in globalState when the ExtensionHost initializes,
ensuring CustomModesManager can find organization modes in agent processes.
* fix(agent-manager): detect mode changes in state updates and call onModeChanged callback
The RuntimeProcessHandler was not detecting mode changes from state updates
sent by the agent process. This fix:
- Adds sessionModes map to track current mode for each session
- Detects mode changes in handleExtensionMessage when processing state updates
- Calls onModeChanged callback when mode changes are detected
- Cleans up sessionModes when sessions are terminated
* chore(agent-manager): add detailed logging for organization mode debugging
Added logging to trace custom modes flow:
- AgentManagerProvider: logs mode slugs and sources when fetching custom modes
- RuntimeProcessHandler: logs mode and custom modes in buildAgentConfig
- agent-runtime process.ts: logs custom modes received from parent
- ExtensionHost: logs custom modes storage in globalState
* fix(agent-runtime): use options.mode for initial state instead of hardcoded 'code'
The ExtensionHost was hardcoding mode to 'code' in the initial state instead
of using the mode passed via options. This fix:
- Adds 'mode' field to ExtensionHostOptions interface
- Passes mode from ExtensionServiceOptions to ExtensionHostOptions
- Uses options.mode (with 'code' fallback) in initial state
- Adds logging to show the initial mode being set
* chore: add detailed logging for API configuration debugging
* fix(agent-manager): address PR review comments
- Disable organization modes temporarily (require additional API config work)
- Use i18n for SessionModeSelector title
- Make previousMode optional in ModeChangedMessage interface
- Remove debug logging
* fix(agent-manager): add portal container for dropdown scrolling
* fix(ui): add overscroll-contain to dropdown for scroll wheel support
* fix(agent-manager): add overflow-y and overscroll-behavior to mode selector content
* Fix comment
* fix(agent-manager): restore mode when resuming sessions
When resuming a session, the mode was not being passed to spawnAgentWithCommonSetup,
causing the agent to always start in 'code' mode regardless of the original session mode.
Now the mode is properly restored from either:
1. sessionData.metadata.mode (from server)
2. session.mode (from local registry)
This ensures that when a user resumes a session that was started in a custom mode
(e.g., 'Brian Mode'), the agent will continue using that mode.
* fix(agent-manager): pass mode to registry when creating session for resume
The mode was being passed to buildAgentConfig (for the agent process) but not
to registry.createSession when creating a new session entry for a resume.
This caused the UI to show 'code' mode even though the agent was running
in the correct mode.
Now the mode is passed to both:
1. buildAgentConfig - for the agent process configuration
2. registry.createSession - for the UI session state
catrielmuller
pushed a commit
that referenced
this pull request
Jan 26, 2026
* feat(agent-manager): add mode selection for CLI sessions
* refactor: extract shared useModeOptions hook to reduce duplication
Addresses PR review comment about duplication between ModeSelector and
SessionModeSelector. The shared hook builds mode dropdown options from
available modes, with optional translation support for the organization
modes header.
* fix: move css-prefix test to src directory for Node.js environment
* fix: isolate mode state per session in Agent Manager
- Add mode to CreateSessionOptions interface in AgentRegistry
- Store mode when creating sessions with DEFAULT_MODE_SLUG fallback
- Add mode to PendingProcessInfo interface in CliProcessHandler
- Pass mode through all session creation paths
- Remove global effectiveModeSlugAtom fallback in SessionModeSelector
- Each session now stores and uses its own mode independently
This fixes the bug where changing the mode in the new session form
would affect the displayed mode in all running sessions.
* fix: add onModeChanged callback to RuntimeProcessHandlerCallbacks and pass mode to createSession
* fix(agent-manager): pass customModes to agent process for organization modes
Organization modes were failing with 'KiloCode token + baseUrl is required
to fetch models' because the agent process didn't have access to the mode
configurations. This fix:
1. Adds customModes parameter to RuntimeProcessHandler.buildAgentConfig()
2. Adds customModes parameter to RuntimeProcessHandler.spawnProcess()
3. Updates AgentManagerProvider.spawnAgentWithCommonSetup() to fetch
custom modes (including organization modes) and pass them to the
agent process
Now the agent process receives all custom mode configurations at startup,
eliminating the need to fetch them from the API during runtime.
* fix(agent-manager): fix mid-session mode switching message format
The extension expects { type: 'mode', text: mode } webview messages,
not { type: 'setMode', mode }. Updated setSessionMode() to send the
correct message format via IPC.
* fix(agent-runtime): store customModes in globalState for organization modes
The CustomModesManager.getCustomModes() method reads organization modes from
globalState.get('customModes'). In agent processes, customModes were only
stored in the currentState but not in globalState, causing organization modes
to fail with 'KiloCode token + baseUrl is required to fetch models' error.
This fix stores customModes in globalState when the ExtensionHost initializes,
ensuring CustomModesManager can find organization modes in agent processes.
* fix(agent-manager): detect mode changes in state updates and call onModeChanged callback
The RuntimeProcessHandler was not detecting mode changes from state updates
sent by the agent process. This fix:
- Adds sessionModes map to track current mode for each session
- Detects mode changes in handleExtensionMessage when processing state updates
- Calls onModeChanged callback when mode changes are detected
- Cleans up sessionModes when sessions are terminated
* chore(agent-manager): add detailed logging for organization mode debugging
Added logging to trace custom modes flow:
- AgentManagerProvider: logs mode slugs and sources when fetching custom modes
- RuntimeProcessHandler: logs mode and custom modes in buildAgentConfig
- agent-runtime process.ts: logs custom modes received from parent
- ExtensionHost: logs custom modes storage in globalState
* fix(agent-runtime): use options.mode for initial state instead of hardcoded 'code'
The ExtensionHost was hardcoding mode to 'code' in the initial state instead
of using the mode passed via options. This fix:
- Adds 'mode' field to ExtensionHostOptions interface
- Passes mode from ExtensionServiceOptions to ExtensionHostOptions
- Uses options.mode (with 'code' fallback) in initial state
- Adds logging to show the initial mode being set
* chore: add detailed logging for API configuration debugging
* fix(agent-manager): address PR review comments
- Disable organization modes temporarily (require additional API config work)
- Use i18n for SessionModeSelector title
- Make previousMode optional in ModeChangedMessage interface
- Remove debug logging
* fix(agent-manager): add portal container for dropdown scrolling
* fix(ui): add overscroll-contain to dropdown for scroll wheel support
* fix(agent-manager): add overflow-y and overscroll-behavior to mode selector content
* Fix comment
* fix(agent-manager): restore mode when resuming sessions
When resuming a session, the mode was not being passed to spawnAgentWithCommonSetup,
causing the agent to always start in 'code' mode regardless of the original session mode.
Now the mode is properly restored from either:
1. sessionData.metadata.mode (from server)
2. session.mode (from local registry)
This ensures that when a user resumes a session that was started in a custom mode
(e.g., 'Brian Mode'), the agent will continue using that mode.
* fix(agent-manager): pass mode to registry when creating session for resume
The mode was being passed to buildAgentConfig (for the agent process) but not
to registry.createSession when creating a new session entry for a resume.
This caused the UI to show 'code' mode even though the agent was running
in the correct mode.
Now the mode is passed to both:
1. buildAgentConfig - for the agent process configuration
2. registry.createSession - for the UI session state
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This PR adds mode selection functionality to the Agent Manager, allowing users to select and switch modes (code, architect, debug, etc.) for CLI sessions.
Features
Mode Selection for New Sessions
KILO_MODEenvironment variableMode Switching During Sessions
setModemessage)modeChangedeventUI Improvements
Technical Changes
modefield tostartSessionMessageSchemaandagentSessionSchemasetModemessage handler inAgentManagerProvidermodeChangedevent handling inuseStdinJsonHandlerModeSelectorandSessionModeSelectorcomponentsDEFAULT_MODE_SLUGconstant across codebaseTesting