Workspace `number` follows creation order, but the sidebar renders grouped by space

[luis-barroso]

Workspace number follows creation order, but the sidebar renders grouped by space

Version: herdr 0.7.5 (stable, Homebrew), macOS 15 (Darwin 25.5.0), Ghostty

Summary

number is assigned in workspace creation order, while the expanded sidebar
renders workspaces grouped by their worktree space. The two orderings only agree
when a user happens to create all of one repo's workspaces consecutively.
Interleave work across two repos and the numbers shown in the expanded sidebar
are no longer monotonic, so they stop being usable as positional identifiers —
which matters most when the sidebar is collapsed and the number is the primary
handle you have.

Reproduce

1. Open a workspace in repo A (herdr worktree open).
2. Open a plain workspace (herdr workspace create, no repo).
3. Open a workspace in repo B.
4. Open a second worktree workspace in repo A.
5. Expand the sidebar and read the numbers top to bottom.

Expected: 1, 2, 3, 4.
Actual: 1, 4, 2, 3 — grouping reorders the rows, numbering does not follow.

Observed

Seven workspaces, created interleaved across two repos. herdr workspace list
returns identical output with the sidebar expanded and collapsed:

number	id	label	worktree.repo_name
1	w1	intocare	intocare
2	w4	portal	portal
3	w6	intocare/ICP-19995-…	intocare
4	w7	navigation	(none)
5	w9	portal/ICP-20047-…	portal
6	wA	intocare/ICP-20009-…	intocare
7	wB	intocare/ICP-20006-…	intocare

Grouped by space, as the expanded sidebar renders them:

intocare      →  1, 3, 6, 7
portal        →  2, 5
(ungrouped)   →  4

So the expanded sidebar reads 1, 3, 6, 7, 2, 5, 4 top to bottom, while the
collapsed rail reads 1, 2, 3, 4, 5, 6, 7. Same seven workspaces, two
orderings, never reconciled.

agent_panel_sort is at its default ("spaces"), and this is the workspace
section of the sidebar, not the agent panel.

number is clearly intended as positional rather than as a stable identifier:
closing a workspace renumbers every workspace after it (closing the workspace at
number: 2 moved the one at 3 to 2, 4 to 3, and so on). That's the right
behaviour for a positional index — it just tracks the wrong sequence.

Why it matters

switch_workspace is documented as an optional indexed binding
("prefix+shift+1..9"). Anyone who enables it and navigates by what they see in
the expanded sidebar will jump to the wrong workspace. Today the mismatch is
cosmetic only because that binding is unset by default.

Suggested fix

Assign number from the rendered order rather than creation order, so it always
matches what the sidebar shows, and renumber when grouping changes — the same
way it already renumbers when a workspace is closed.

[kangal-bot]

hi @luis-barroso, thanks for opening this.

this issue does not appear to use the full bug report template. herdr issues are only for reproducible bugs and maintainer-created or maintainer-converted work items.

bug reports must include the reproducible-bug confirmation, current behavior, expected behavior, reproduction, impact, and environment fields with herdr version, update channel, operating system, and terminal.

feature requests, ideas, questions, contribution proposals, and direction checks belong in discussions:
https://github.com/herdrdev/herdr/discussions

please read the contributing guidelines before opening issues or prs:
https://github.com/herdrdev/herdr/blob/master/CONTRIBUTING.md

closing this so the issue tracker stays limited to actionable bug reports.

[luis-barroso]

Sorry about the format — I opened that without reading CONTRIBUTING.md first, and it had analysis and a proposed fix in it that shouldn't have been there. Here it is again using the bug template, with the diagnosis stripped out. Could you reopen if it looks actionable?

I've moved the "what should the number track" part to a discussion, since that's a direction question rather than part of the report.

---

Is this a reproducible bug?

• I confirm this is a reproducible bug, not a feature request, idea, question, contribution proposal, or direction check.
• I reproduced this bug on the version and environment reported below using the exact steps provided.

Current behavior

With the sidebar expanded, the workspace rows appear in one order. Collapsing the sidebar shows the same workspaces in a different order, so a workspace sits at a different position depending on whether the sidebar is expanded or collapsed.

herdr workspace list returns the same number for each workspace in both states.

Expected behavior

Workspace rows appear in the same order whether the sidebar is expanded or collapsed.

Reproduction

1. Open the parent workspace for repo A.
2. Open the parent workspace for repo B.
3. Open a worktree workspace in repo A.
4. Expand the sidebar and note the order of the workspace rows.
5. Collapse the sidebar and compare the order.

Impact

With the sidebar collapsed I cannot tell which workspace is which by position, so I have to expand it first before switching.

Environment

• Herdr version: 0.7.5
• Update channel (stable or preview): stable (Homebrew)
• Operating system: macOS 15 (Darwin 25.5.0)
• Terminal: Ghostty
• Shell, if relevant: zsh
• Relevant config, if any: [ui] at defaults (agent_panel_sort = "spaces"), keys.prefix = "ctrl+a"