Repository navigation
A workspace closing itself switches me out of the workspace I'm working in #1621
Description
Is this a reproducible bug?
- I confirm this is a reproducible bug, not a feature request, idea, question, contribution proposal, or direction check.
Current behavior
When a workspace closes itself because its last pane's process ended, the focus
moves off the workspace I was working in.
With workspaces X, Y, Z and me working in Y: when X's last pane ends,
X closes itself and the focus moves from Y to Z.
It depends on position. I tried each combination:
- working in
Y,X(before it) closes -> focus moves toZ← the problem - working in
Y,Z(after it) closes -> focus stays onY - working in
Z(last in the list),Xcloses -> focus stays onZ - only two workspaces,
Xcloses while inY-> focus stays onY
So it happens when the workspace that closes sits before mine, and mine is not
the last one in the list.
Related but different: discussion #1328 is about explicitly closing a workspace.
Here I don't close anything — the workspace closes on its own.
Expected behavior
A workspace closing itself removes that workspace and leaves me on the
workspace I was working in.
Reproduction
- Create three workspaces in this order:
X,Y,Z. - Focus
Y, the middle one. - In
X, end the last pane's process — typingexitin its shell does it. Xdisappears, and the focus moves fromYtoZ.
Impact
I get moved to a different workspace with no action on my part and no
indication, so I can start typing into a terminal I didn't mean to be in.
I should be upfront that the conditions are narrow: a workspace has to be down
to a single pane whose process ends by itself, and it has to sit before my
current workspace while mine isn't last. An interactive agent won't trigger it,
since those keep running. I ran into it with a one-shot process; a crash or a
dropped connection would do the same.
Environment
- Herdr version: 0.7.4
- Update channel (stable or preview): stable
- Operating system: macOS 26.3.1
- Terminal: WezTerm
- Shell, if relevant: zsh
- Relevant config, if any: none
Activity
zjbecker commentedon Jul 24, 2026
Hitting this too, on 0.7.5. Worth noting it's not limited to a process exiting on its own - a plain
herdr pane closeon the last pane of a background (non-active) workspace triggers the exact same focus jump.fix: keep focus on the current workspace when another self-closes
fix: keep focus on the current workspace when another self-closes
fix: don't steal focus on pane or workspace close
fix: don't steal focus when the API closes a background workspace
fix: keep focus on the current workspace when another self-closes (#1912
kangal-bot commentedon Jul 27, 2026
Implemented on master and queued for the next release. This is not available in a published Herdr release yet.
kunchenguid commentedon Jul 28, 2026
This is exactly what I am seeing on 0.7.5 stable when an orchestrator runs
pane.closeon the only pane in a background workspace.I captured 19 server-confirmed focus moves in one day. My cleanup snapshots the focused tab and restores it 56-197 ms later, but that window is still long enough for keystrokes to land in the wrong pane. I did not capture the visual flash directly, so the measured claim here is the focus move and restore timing.
Environment: Herdr 0.7.5 stable, protocol 17, macOS 26.5.2, WezTerm, zsh.
I found this existing report while checking for duplicates, and the pending-release note looks like it covers the same path, so I am adding the operational impact here instead of opening another issue.
ogulcancelik commentedon Jul 28, 2026
@kunchenguid thanks for searching past issues before creating another one! i verified this is fixed on master, captain :)
kangal-bot commentedon Jul 29, 2026
Released on the preview channel in 2026-07-29-44b3adb12552. This is available to preview users, but is not in a stable Herdr release yet.
kangal-bot commentedon Aug 3, 2026
Released in v0.8.0.
fix: keep focus on the current workspace when another self-closes (he…
Integrate/upstream v0.8.0 (#1)
docs: document stacked panes wherever splitting is documented
fix: make the pane menu's stack action work, and stop calling it a split
refactor: delete the cfg(test) context menu dispatch mirror
rename: keys.split_stacked becomes keys.stack_pane
fix: keep focus on the current workspace when another self-closes (he…