Can't navigate in the Tab name dialog

[gabemisura]

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

Creating a new tab or renaming an existing tab, you're unable to navigate within the tab's name. I wanted to change the name of my tab by adding something at the beginning so I tried control+a, nothing happened. I tried the arrow keys, nothing happened. I had to delete everything, add the text at the beginning and retype everything that was there previously.

Expected behavior

Control+a takes me to the beginning of the tab name.
Arrow keys move the cursor so I can insert/delete text at a specific point, not only at the end.

Reproduction

Create a new tab, type: new tab, then hit control+a - you don't go to the beginning of the tab name field.
Rename an existing tab, hit control+a - you don't go to the beginning of the tab name field.

Impact

slow, annoying.

Environment

• Herdr version: 0.7.4
• Update channel (stable or preview): stable
• Operating system: MacOS 26.5.2
• Terminal: iterm2
• Shell, if relevant: zsh
• Relevant config, if any: nothing relevant I can think of.

[corrius]

I have a working version of this. I’ve added cursor-aware text editing to the workspace, tab, and pane naming dialogs, reusing shared rename-input helpers for navigation, insertion, deletion, paste, UTF-8 handling, and horizontal scrolling while keeping worktree input behavior unchanged.

If this approach looks good to you, I can open a PR with the implementation.

[saschabratton]

@corrius I wasn't sure if this is actually a bug or a feature request. I would like this functionality as well, and likewise have a working local version. I opened this discussion: #2337

Whether this would be considered a feature implementation or bug fix, I would like to have this functionality.

[saschabratton]

This is my local implementation: https://github.com/saschabratton/herdr/pull/1/changes

[iappwebdev]

Confirming this on Windows 11 with 0.8.0-preview.2026-08-04 — so it is not macOS- or 0.7.4-specific, and it is still present on the current preview channel.

Same symptoms: Home, Ctrl+A and the arrow keys do nothing in the rename dialog, so the only way to change a long tab name is to clear it and retype. Ctrl+U (clear line) does work, which softens the deleting part but not the "insert something at the beginning" case.

For what it is worth, tab names in agent workspaces get long quickly (mine run to ~35 characters), so this hits on basically every rename.

+1 for either implementation landing.

[kyleliu-code]

Confirming on 0.8.0 stable (macOS 14.7.8, kitty 0.46.2) — still reproduces.

Worth noting this isn't a key-parsing or terminal-specific issue: the rename input has no cursor at all. state.name_input is a plain String and the only edit primitives are append-to-end / pop-from-end.

src/app/input/modal.rs @ v0.8.0:

// :612
pub(crate) fn insert_rename_input_text(state: &mut AppState, text: &str) {
    if state.name_input_replace_on_type { clear_rename_input(state); }
    state.name_input.push_str(text);          // append only
}
// :619
fn delete_rename_input_char(state: &mut AppState) {
    if state.name_input_replace_on_type { clear_rename_input(state); }
    else { state.name_input.pop(); }          // pop only
}

handle_rename_edit_key (:675) matches only Ctrl+U, Cmd+Backspace, Ctrl/Alt+Backspace, Ctrl+H/Ctrl+W, Backspace, and plain chars. Left/Right/Home/End/Ctrl+A/Ctrl+E all fall through to _ => {} and are silently dropped — which is why this reproduces identically on macOS/kitty, macOS/iTerm2, Windows 11, and Arch/alacritty (#727).

Also flagging that #727 was closed as completed on 2026-06-21, but the behavior is unchanged in 0.8.0 stable.

Two working implementations are already on offer in this thread — a direction call seems to be the only thing blocking a PR.

[kouyichi]

Same problem here on Linux, herdr 0.8.0 stable. Confirming and adding one more symptom: Backspace also does not work in the rename dialog (pressing it does nothing — the character stays). Only typing at the end and Enter work. So line editing in the tab/workspace rename input is effectively broken: no ctrl+a, no arrow keys, no backspace. This is a daily annoyance for anyone who mistypes a name.

Environment: Linux x86_64 (TencentOS-like container), herdr 0.8.0 stable, terminal: kitty/gnome-terminal, shell: bash.

Would be great if the rename input supported standard line editing (backspace, left/right, ctrl+a/ctrl+e). Happy to test a fix.

[kouyichi]

We reproduced this on Linux with herdr 0.8.0 stable (see my earlier comment) and implemented a fix. Since unsolicited PRs are closed per CONTRIBUTING, the work lives on a fork branch for your maintainer-owned agent to pick up:

Branch: https://github.com/kouyichi/herdr/tree/fix-rename-input-editing
Commit: 7dfcb25 "fix(input): support line editing in rename modal inputs"

What it adds to the rename dialogs (tab / workspace / pane, shared name_input):

• Ctrl+A / Ctrl+E and Home / End jump the caret to start / end (Ctrl+A from Can't navigate in the Tab name dialog #1803)
• Left / Right move the caret
• Backspace deletes before the caret, Delete deletes at the caret (covers terminals that encode Backspace as CSI 3 ~)
• Ctrl+W / Ctrl+Backspace / Alt+Backspace delete the word before the caret
• the caret renders at its position in the rename and new-worktree dialogs
• caret is byte-indexed and clamped to char boundaries, so CJK names edit safely

Implementation notes:

• AppState gains name_input_cursor (byte offset, clamped via clamp_name_input_cursor); all rename/open/cancel/clear entry points seed or reset it
• handle_rename_edit_key in src/app/input/modal.rs dispatches the new keys; worktree-create editing uses the same caret-aware helpers
• rendering (src/ui/dialogs.rs) shows the caret marker at the cursor; note this touches the same overlay area as fix(ui): anchor the host cursor to modal name inputs #2569, so the two will need a small rebase when both land

Testing: 14/14 rename-modal tests pass, including new coverage for caret movement, insert-at-caret, Backspace/Delete at caret, Ctrl+A/Ctrl+E/Home/End, CJK char-boundary safety, and word-delete at caret. Full suite: 3118 passed; the only failure is pre-existing on clean master in this environment (detect::tests::foreground_job_detects_agent_behind_shell_wrapper, unrelated to input handling). cargo fmt --check is clean.

Happy to adjust anything or rebase onto #2569 if that helps.

[kouyichi]

Follow-up on the same rename-input area: Backspace can still wipe the entire name in one press, even with the line-editing support in place.

Root cause

Two independent bugs:

1. Legacy ^H terminals. Terminals that emit 0x08 (ASCII BS, the classic Backspace byte) for the Backspace key are parsed by parse_legacy_ctrl_char as Ctrl+H. The rename modal treated Ctrl+H as word-delete, so for single-token names ("1", "my-codex") one Backspace press deleted the whole string. Reproduced on Linux v0.8.0 stable and on current master via pty: type abcde in the rename dialog, send 0x08 → input becomes empty.

2. replace-on-type dialogs wipe on delete. Dialogs opened with name_input_replace_on_type = true (new tab, new workspace, pane rename without label, linked-worktree branch prefill) call clear_rename_input() on Backspace/Delete/word-delete — the entire prefill vanishes instead of one char being removed.

Fix (branch kouyichi/herdr@fix-rename-backspace-wipe, commits 2b63c04 + 589b832)

• parse_legacy_ctrl_char: map 0x08 → KeyCode::Backspace (same as 0x7f), so ^H-emitting terminals get working erase in every herdr-owned field (rename dialogs, navigator, search) instead of a spurious Ctrl+H. Pane passthrough is unaffected (raw vt bytes are still forwarded).
• Rename modal delete helpers (delete_rename_input_char/_after/_word): deletion is editing, not replacement — remove the actual char(s) at/before the caret and clear the replace flag, so the next keystroke appends instead of replacing.
• Split Ctrl+H from Ctrl+W in the modal: ^H = delete one char (readline/tmux convention), Ctrl+W stays word-delete.
• Same one-char-delete fix applied to the linked-worktree create dialog (it duplicated the wipe logic).

Verification

• 17 rename-modal tests + 1 new worktree test + raw_input family matrix (0x08 → Backspace) all pass.
• Full suite: 3117 pass; the 8 failures are pre-existing environment/parallelism flakiness (verified individually — plugins/clipboard/pty tests pass in isolation; foreground_job_detects_agent_behind_shell_wrapper fails on clean master too).
• pty end-to-end on the fixed build: 0x7f and 0x08 both delete exactly one char in the tab-rename dialog; new-tab dialog backspace deletes one char from the prefill.

[s0up4200]

The same problem is present in the worktree rename input in the spaces tab, which looks like it is out of scope for the fixes proposed above (@corrius mentions keeping worktree input behavior unchanged).

Steps: open the spaces tab, rename a worktree, then press Ctrl+A or the arrow keys. The cursor stays at the end. To put text before the existing name, you must delete the name and type it again.

Left-clicking anywhere inside the rename dialog closes it, unless the click lands on save, clear, or cancel — the title row, the padding and the border all dismiss it. Say if that is better as a separate report.

Herdr 0.8.0, stable channel, Arch Linux (Omarchy), Alacritty, bash.

[saschabratton]

The same problem is present in the worktree rename input in the spaces tab, which looks like it is out of scope for the fixes proposed above

@s0up4200 The implementation I shared above also covers worktree (and workspace and pane) rename inputs, not just tab rename.

see: https://github.com/saschabratton/herdr/pull/1/changes

The only inputs I skipped (other than literally input inside the terminal panes) are the search/filter inputs. I would be happy to include those as well, but I am personally only concerned with the rename inputs where it feels more applicable (vs substring searching) and so would scope the rename input changes separately.

If taking on search inputs, I think also adding nucleo should be considered, but that's maybe something for discussion.