Motivation
Terminal capability detection currently relies entirely on environment variables ($TERM_PROGRAM, $KITTY_WINDOW_ID, etc.), which have known false-positive/false-negative risks accepted for v0.x per docs/spec/terminal-detection.md's "Known false-negative / false-positive risks" section: $TERM_PROGRAM can be spoofed or left stale by nested tools/SSH sessions, and $KITTY_WINDOW_ID can persist into subshells/nested sessions even when the actual terminal on the other end isn't kitty.
Proposed Solution
Add a DA1 (\x1b[c) or XTGETTCAP query as a stronger capability check layered on top of (not replacing) the existing env-var detection, per docs/spec/terminal-detection.md's "Future considerations (not implemented)" section. This requires reading a terminal response asynchronously — the same category of complexity as #9's async response handling — so the two issues likely share infrastructure (an async stdin reader that can recognize different kinds of terminal responses) and should be coordinated or sequenced together.
Alternatives Considered
- Status quo (env vars only): simple, has no async-stdin-reading complexity, and the known risks are narrow/documented edge cases (nested/SSH sessions) rather than the common case — this is why it wasn't blocking for v0.x.
Additional Context
Out of scope until a measured real-world need (actual false-detection reports) justifies the added complexity, per the spec memo's own framing. This issue exists to track the idea, not to signal it's urgent.
Checklist
Motivation
Terminal capability detection currently relies entirely on environment variables (
$TERM_PROGRAM,$KITTY_WINDOW_ID, etc.), which have known false-positive/false-negative risks accepted for v0.x perdocs/spec/terminal-detection.md's "Known false-negative / false-positive risks" section:$TERM_PROGRAMcan be spoofed or left stale by nested tools/SSH sessions, and$KITTY_WINDOW_IDcan persist into subshells/nested sessions even when the actual terminal on the other end isn't kitty.Proposed Solution
Add a DA1 (
\x1b[c) or XTGETTCAP query as a stronger capability check layered on top of (not replacing) the existing env-var detection, perdocs/spec/terminal-detection.md's "Future considerations (not implemented)" section. This requires reading a terminal response asynchronously — the same category of complexity as #9's async response handling — so the two issues likely share infrastructure (an async stdin reader that can recognize different kinds of terminal responses) and should be coordinated or sequenced together.Alternatives Considered
Additional Context
Out of scope until a measured real-world need (actual false-detection reports) justifies the added complexity, per the spec memo's own framing. This issue exists to track the idea, not to signal it's urgent.
Checklist