Problem
Every socket/CLI worktree and tab action moves the in-app selection and keyboard
focus to the affected worktree:
supacode repo worktree-newsupacode tab newsupacode worktree deletesupacode worktree run / stop
When Supacode is driven from external orchestration tooling — a "lead" agent
session running in one Supacode tab that programmatically creates worktrees,
spawns worker tabs, and tears them down — each of those commands yanks focus
away from the tab I'm actively working in and over to the newly-affected
worktree's terminal. During a busy session that's dozens of focus jumps out of
the tab I'm typing in.
To be precise about the mechanism (this is in-app focus, not window activation):
the CLI worktree-action reducer dispatches
.selectWorktree(worktreeID, focusTerminal: true)
selectWorktree sets the single-worktree selection and, with
focusTerminal: true, focuses that worktree's terminal — so keyboard focus
leaves the caller's tab. It's gated only by Deeplink.WorktreeAction.selectsWorktree,
which is hard-coded true for every action except appearance / tabRename:
// Deeplink.swift
/// Whether dispatching this action should also select / focus the worktree.
/// Metadata-only updates (appearance, tab rename) skip it so they don't steal focus.
var selectsWorktree: Bool {
switch self {
case .appearance, .tabRename: false
default: true
}
}So the "don't steal focus" path already exists for metadata-only actions — there's
just no way to opt lifecycle actions into it. No settings.json key and no CLI
flag currently suppresses it.
Request
A way to opt out of the select/focus-follow for CLI- and deeplink-issued actions,
so a programmatic driver can create/delete worktrees and spawn tabs without
stealing focus from the tab the user is in. Either:
- A global setting — e.g. "Don't change focus on CLI/deeplink worktree
actions" (analogous to the existing automatedActionPolicy), or
- A per-command flag —
--no-focus on worktree-new, tab new,
worktree delete, worktree run (dispatch the action with
focusTerminal: false and skip the selectWorktree).
Keeping the current focus-follow as the default is fine; the ask is just an
opt-out for programmatic drivers.
Today the only workaround is to snap focus back after the fact with
supacode tab focus -w <caller-worktree> -t <caller-tab>, which works but
produces a visible focus bounce (focus jumps to the new worktree, then back).
Not a duplicate of #721
#721 is the app hanging on tab switches. This is intentional focus-follow being
unconditional for CLI actions — a separate, working-as-coded behavior I'd like to
be able to turn off.
Problem
Every socket/CLI worktree and tab action moves the in-app selection and keyboard
focus to the affected worktree:
supacode repo worktree-newsupacode tab newsupacode worktree deletesupacode worktree run/stopWhen Supacode is driven from external orchestration tooling — a "lead" agent
session running in one Supacode tab that programmatically creates worktrees,
spawns worker tabs, and tears them down — each of those commands yanks focus
away from the tab I'm actively working in and over to the newly-affected
worktree's terminal. During a busy session that's dozens of focus jumps out of
the tab I'm typing in.
To be precise about the mechanism (this is in-app focus, not window activation):
the CLI worktree-action reducer dispatches
selectWorktreesets the single-worktree selection and, withfocusTerminal: true, focuses that worktree's terminal — so keyboard focusleaves the caller's tab. It's gated only by
Deeplink.WorktreeAction.selectsWorktree,which is hard-coded
truefor every action exceptappearance/tabRename:So the "don't steal focus" path already exists for metadata-only actions — there's
just no way to opt lifecycle actions into it. No
settings.jsonkey and no CLIflag currently suppresses it.
Request
A way to opt out of the select/focus-follow for CLI- and deeplink-issued actions,
so a programmatic driver can create/delete worktrees and spawn tabs without
stealing focus from the tab the user is in. Either:
actions" (analogous to the existing
automatedActionPolicy), or--no-focusonworktree-new,tab new,worktree delete,worktree run(dispatch the action withfocusTerminal: falseand skip theselectWorktree).Keeping the current focus-follow as the default is fine; the ask is just an
opt-out for programmatic drivers.
Today the only workaround is to snap focus back after the fact with
supacode tab focus -w <caller-worktree> -t <caller-tab>, which works butproduces a visible focus bounce (focus jumps to the new worktree, then back).
Not a duplicate of #721
#721 is the app hanging on tab switches. This is intentional focus-follow being
unconditional for CLI actions — a separate, working-as-coded behavior I'd like to
be able to turn off.