[BUG] Unrecognized TERM_PROGRAM=herdr adds ~3s to interactive startup; TERM_PROGRAM=ghostty starts immediately

Status Open
Reported on v2.1.287
Maintainer reply None cached
Activity 1 comment · opened Oct 1, 2026

Preflight Checklist

  • [x] I searched existing issues and did not find this exact startup-latency regression.
  • [x] This is reproducible with a controlled A/B where only TERM_PROGRAM changes.
  • [x] I am using the latest Claude Code version available in my environment.

What's Wrong?

Interactive Claude Code startup is ~3 seconds slower when launched inside Herdr 0.9.3, which sets:

TERM_PROGRAM=herdr
TERM_PROGRAM_VERSION=0.9.3

Changing only TERM_PROGRAM to ghostty makes the initial Claude Code UI appear almost immediately.

This is not a first-prompt / first-Enter delay. The delay occurs before the initial interactive TUI is painted.

Environment

  • macOS
  • Claude Code: 2.1.287
  • Host terminal: Ghostty 1.3.1
  • Multiplexer: Herdr 0.9.3
  • Shell: zsh
  • Inside Herdr:
  • TERM_PROGRAM=herdr
  • TERM_PROGRAM_VERSION=0.9.3

Reproduction

Inside a Herdr pane:

claude

Observed: the initial Claude Code screen appears after roughly 3 seconds.

Now launch the same binary from the same Herdr pane, changing only TERM_PROGRAM:

TERM_PROGRAM=ghostty claude

Observed: the initial Claude Code screen appears almost immediately.

The underlying host terminal is Ghostty 1.3.1.

Terminal capability probes

I also checked whether this was simply a terminal capability-query timeout.

Directly in Ghostty:

repr: b'\x1bP>|ghostty 1.3.1\x1b\\\x1b[?62;22;52c'
hex : 1b 50 3e 7c 67 68 6f 73 74 74 79 20 31 2e 33 2e 31 1b 5c 1b 5b 3f 36 32 3b 32 32 3b 35 32 63

Inside Herdr:

repr: b'\x1bP>|libghostty\x1b\\\x1b[?62;22c'
hex : 1b 50 3e 7c 6c 69 62 67 68 6f 73 74 74 79 1b 5c 1b 5b 3f 36 32 3b 32 32 63

So Herdr does answer XTVERSION / DA1 promptly. The latency appears to be tied to Claude Code taking a different startup path for the unrecognized TERM_PROGRAM=herdr identity, rather than Herdr failing to answer the basic capability probes.

Expected Behavior

Claude Code should start with comparable latency in a capable terminal multiplexer regardless of whether its TERM_PROGRAM value is on a hard-coded allowlist.

Ideally terminal capabilities should be detected from capability responses where possible, with terminal-name identity used only as a fallback.

Actual Behavior

TERM_PROGRAM=herdr    -> initial UI ~3s
TERM_PROGRAM=ghostty  -> initial UI almost immediate

Same Claude binary, same cwd, same Herdr pane, same environment otherwise.

Related Issues

  • #88362 — interactive startup behavior changes dramatically based on TERM_PROGRAM
  • #97501 — claude attach does not probe kitty keyboard capability for terminals outside the TERM_PROGRAM allowlist
  • #71700 — kitty keyboard protocol was gated on terminal-name allowlist instead of CSI ? u capability
  • #83508 — unrecognized TERM_PROGRAM disables OSC 8 hyperlink behavior

There is also a related Herdr-side compatibility change: since Herdr 0.9.2, panes intentionally advertise TERM_PROGRAM=herdr instead of inheriting the outer terminal identity. That avoids stale host-terminal session identity, but it exposes Claude Code paths that depend on recognizing specific terminal names.

Additional Context

A separate Shift+Enter issue may share the same terminal-identification/capability-negotiation axis, but I am keeping this report focused on the reproducible startup latency.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗