fix(core): ensure TERM env var is passed to editors and shells

[rmedranollamas]

Summary

Ensure the TERM and COLORTERM environment variables are correctly passed to editors (like Emacs) and interactive shell commands, preventing failures when these variables are missing or redacted.

Details

• Added TERM and COLORTERM to the whitelist of always allowed environment variables in packages/core/src/services/environmentSanitization.ts.
• Updated ShellExecutionService to use the host's TERM variable with a fallback to xterm-256color, instead of hardcoding the fallback value.
• Updated openFileInEditor to explicitly pass TERM and COLORTERM to spawned editor processes, ensuring terminal-based editors have the necessary context to initialize.

Related Issues

Fixes #20444

How to Validate

1. Set your EDITOR or VISUAL to emacs (terminal mode).
2. Attempt to open a file or edit a plan in Gemini CLI.
3. Verify that Emacs starts correctly without "Terminal type not defined" errors.
4. Run an interactive shell command via the CLI (e.g., run_shell_command top) and verify it correctly identifies the terminal type.

Pre-Merge Checklist

• Updated relevant documentation and README (if needed)
• Added/updated tests (if needed) - N/A (Existing tests cover general execution)
• Noted breaking changes (if any)
• Validated on required platforms/methods:
  • MacOS
    • npm run

[gemini-code-assist]

Summary of Changes

Hello @rmedranollamas, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses issues where terminal-based editors and interactive shell commands might fail due to missing or redacted TERM and COLORTERM environment variables. By explicitly passing these variables to spawned processes and whitelisting them in the environment sanitization, it ensures proper terminal identification and functionality across various tools, improving the reliability of external command execution.

Highlights

• Editor Environment Variables: Ensured TERM and COLORTERM environment variables are explicitly passed to spawned editor processes, preventing terminal-related failures.
• Environment Variable Whitelisting: Whitelisted TERM and COLORTERM in the environment sanitization service to ensure they are always preserved.
• Shell Execution TERM Handling: Updated ShellExecutionService to use the host's TERM variable when available, falling back to xterm-256color for interactive shell commands.

Changelog

• packages/cli/src/ui/utils/editorUtils.ts
  • Explicitly set TERM and COLORTERM in the env option for spawnSync when opening files in an editor.
  • Explicitly set TERM and COLORTERM in the env option for spawn when opening files in an editor.
• packages/core/src/services/environmentSanitization.ts
  • Added TERM to the ALWAYS_ALLOWED_ENVIRONMENT_VARIABLES set.
  • Added COLORTERM to the ALWAYS_ALLOWED_ENVIRONMENT_VARIABLES set.
• packages/core/src/services/shellExecutionService.ts
  • Modified the TERM environment variable assignment for spawn to use process.env['TERM'] if available, otherwise xterm-256color.
  • Modified the TERM environment variable assignment for exec to use process.env['TERM'] if available, otherwise xterm-256color.

Activity

• The author noted that existing tests cover general execution, so no new tests were added.
• The changes were validated on MacOS using npm run.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request correctly identifies the need to pass TERM and COLORTERM environment variables to child processes to ensure proper functionality of terminal-based editors and shells. The changes to whitelist these variables in environmentSanitization.ts and to pass them when spawning editors in editorUtils.ts are well-implemented. However, the fix is incomplete in shellExecutionService.ts, where a fallback for COLORTERM is missing for shell commands, potentially leading to inconsistent color support. I've added comments with suggestions to address this for a more robust solution.

[jacob314]

pretending the terminal is truecolor when it isn't seems dangerous. Can we just pass exactly what was in the process rather than lying about it.

[jacob314]

Should we be really claiming the terminal is truecolor when it is not? I would suggest we omit this or use the existing detection logic we already have for whether the terminal appears to be true color (used for warnings we show when the terminal is not true color).