You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
New session spawned from keyboard shortcut inherits current mode instead of respecting default_agent #29594
When starting a new session from an existing session using a keyboard shortcut (e.g. while in build mode), the new session opens in build mode rather than respecting the default_agent config setting.
Expected behaviour
A new session should always open using the agent specified in default_agent. In my case, "default_agent": "plan" is set in ~/.config/opencode/opencode.json, so new sessions should open in plan mode regardless of the current session's mode.
Actual behaviour
The new session inherits the mode of the session it was spawned from. If the current session is in build mode, the new session also opens in build mode.
Config
{
"default_agent": "plan"
}
Environment
OpenCode version: 1.14.31
OS: macOS (darwin)
Terminal: TUI
Steps to reproduce
Set "default_agent": "plan" in config
Open OpenCode (starts correctly in plan mode)
Switch to build mode with Tab
Start a new session via keyboard shortcut
Observe the new session opens in build mode instead of plan mode
This issue might be a duplicate of existing issues. Please check:
[FEATURE]:Option to always start sessions in the configured default agent mode #27370: Same root issue — default_agent config not being respected when sessions are opened; that issue covers resumed sessions opening in the wrong mode, which overlaps closely with this report about new sessions spawned from a keyboard shortcut inheriting the current mode instead of using default_agent.
For keybind-related issues, please also check our pinned keybinds documentation: #4997
Keybinds can't fix this. I've reviewed the keybinds documentation and the full list of configurable actions in tui.json. There's no action or modifier that controls which agent mode session_new uses — it's not a keybind configuration issue.
The fix needs to be in the session_new handler itself: when creating a new session, it should read default_agent from config rather than inheriting the current session's active agent.
Activity
github-actions commentedon May 27, 2026
This issue might be a duplicate of existing issues. Please check:
default_agentconfig not being respected when sessions are opened; that issue covers resumed sessions opening in the wrong mode, which overlaps closely with this report about new sessions spawned from a keyboard shortcut inheriting the current mode instead of usingdefault_agent.For keybind-related issues, please also check our pinned keybinds documentation: #4997
pt-james-woszczynski commentedon May 28, 2026
Thanks for the triage. I've reviewed both #27370 and the keybinds docs at #4997, but I don't think either applies here:
Not a duplicate of [FEATURE]:Option to always start sessions in the configured default agent mode #27370. That issue is about resumed sessions ignoring
default_agent(session state persistence overriding config). My issue is about newly created sessions inheriting the current session's mode instead of readingdefault_agentfrom config. The trigger and likely code path are different — [FEATURE]:Option to always start sessions in the configured default agent mode #27370 is a persistence/restore problem, this is a session creation problem.Keybinds can't fix this. I've reviewed the keybinds documentation and the full list of configurable actions in
tui.json. There's no action or modifier that controls which agent modesession_newuses — it's not a keybind configuration issue.The fix needs to be in the
session_newhandler itself: when creating a new session, it should readdefault_agentfrom config rather than inheriting the current session's active agent.Happy to provide any additional info needed.
github-actions commentedon Jul 28, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.