fix(cli): set TERM, COLORTERM, and LANG defaults for terminal pty sessions#495
fix(cli): set TERM, COLORTERM, and LANG defaults for terminal pty sessions#495GeT-LeFt wants to merge 3 commits intotiann:mainfrom
Conversation
…sions Terminals spawned by the hub inherit a filtered process.env, but when the hub itself is started via launchd, systemd, or Docker, these variables are often missing: - TERM unset → programs fall back to "dumb", disabling colors and cursor movement - COLORTERM unset → shells/prompts (e.g. p10k) skip truecolor output - LANG unset → non-ASCII glyphs (powerline symbols, emoji) render as replacement characters Add sensible defaults (`xterm-256color`, `truecolor`, `en_US.UTF-8`) only when the value is not already present, so explicit user overrides are still respected.
There was a problem hiding this comment.
Findings
- [Major] Hard-coded
en_US.UTF-8is not portable for Docker/systemd deployments. Minimal Debian-based images commonly do not have that locale generated, so each new PTY can start withlocale: Cannot set LC_*...warnings and locale-dependent tools inherit an invalid locale. Evidence cli/src/terminal/TerminalManager.ts.
Suggested fix:if (!env.LANG) { env.LANG = process.platform === 'darwin' ? 'en_US.UTF-8' : 'C.UTF-8' }
Summary
Review mode: initial
One portability regression found in the new terminal env defaults: the fallback locale at cli/src/terminal/TerminalManager.ts is not safe for minimal Debian-based Docker images, which this PR explicitly targets.
Testing
- Not run (automation)
- Add a unit test for
buildFilteredEnv()that covers missing locale vars on Linux and preserves an existingLANGoverride.
HAPI Bot
| env.COLORTERM = 'truecolor' | ||
| } | ||
| if (!env.LANG) { | ||
| env.LANG = 'en_US.UTF-8' |
There was a problem hiding this comment.
[MAJOR] en_US.UTF-8 is not generated in common minimal Debian-based Docker images, so this fallback can make every spawned PTY print locale: Cannot set LC_*... on startup and leaves locale-sensitive tools in an invalid locale state.
Suggested fix:
if (!env.LANG) {
env.LANG = process.platform === 'darwin' ? 'en_US.UTF-8' : 'C.UTF-8'
}There was a problem hiding this comment.
Findings
- [Major] Hard-coded
en_US.UTF-8is not portable for Docker/systemd deployments. Minimal Debian-based images commonly do not have that locale generated, so each new PTY can start withlocale: Cannot set LC_*...warnings and locale-dependent tools inherit an invalid locale. Evidencecli/src/terminal/TerminalManager.ts:78.
Suggested fix:if (!env.LANG) { env.LANG = process.platform === 'darwin' ? 'en_US.UTF-8' : 'C.UTF-8' }
Summary
Review mode: follow-up after new commits
The only commit after the prior HAPI Bot review is a CI retrigger, so the PR code diff is unchanged. The locale fallback issue remains on the latest head and still affects the Docker/systemd use case described by the PR.
Testing
- Not run (automation)
- Add a unit test for
buildFilteredEnv()that covers missing locale vars on Linux and preserves an existingLANGoverride.
HAPI Bot
| env.COLORTERM = 'truecolor' | ||
| } | ||
| if (!env.LANG) { | ||
| env.LANG = 'en_US.UTF-8' |
There was a problem hiding this comment.
[MAJOR] en_US.UTF-8 is not generated in common minimal Debian-based Docker images, so this fallback can make every spawned PTY print locale: Cannot set LC_*... on startup and leaves locale-sensitive tools in an invalid locale state.
Suggested fix:
if (!env.LANG) {
env.LANG = process.platform === 'darwin' ? 'en_US.UTF-8' : 'C.UTF-8'
}Address review feedback: minimal Debian-based Docker images often do not have en_US.UTF-8 generated, causing locale warnings. Use C.UTF-8 (always available) on Linux, keep en_US.UTF-8 on macOS.
There was a problem hiding this comment.
Findings
No issues found in the modified lines.
Summary
Review mode: follow-up after new commits
The previous HAPI Bot finding about the non-portable Linux locale fallback is addressed by using C.UTF-8 off macOS. Residual risk: buildFilteredEnv() still has no direct unit coverage for preserving existing env values and applying defaults when TERM, COLORTERM, or LANG are missing.
Testing
Not run (automation; did not execute PR code). Suggested coverage: add a unit test for buildFilteredEnv() covering missing terminal env defaults and preservation of parent overrides.
HAPI Bot
Problem
When the hub process is started via launchd (macOS), systemd, or Docker, the spawned terminal PTY sessions inherit a stripped-down environment that is missing critical terminal variables:
TERMdumbmode — no colors, no cursor movementCOLORTERMLANG�This makes the web terminal nearly unusable for anyone running common shell setups like oh-my-zsh or p10k.
Solution
Set sensible defaults in
buildFilteredEnv()only when the variable is not already present, so explicit user overrides via the parent process are respected:TERM=xterm-256colorCOLORTERM=truecolorLANG=en_US.UTF-8Testing
TERM/LANGvalues from parent env are preserved (not overwritten)Fixes #498