[Bug] Resumed session injects COLORTERM=truecolor and changes prompt highlight color

Describe the bug

Resuming a Copilot CLI session can inject COLORTERM=truecolor into the spawned session process even though the launching shell and parent Copilot process have COLORTERM unset. This changes the submitted-user-prompt highlight from the terminal-palette green rendering to a gray truecolor background.

The result is inconsistent UI rendering between two Copilot sessions launched by the same WSL user, with the same global theme: "github" setting, the same Windows Terminal profile, and TERM=xterm-256color.

Process inspection showed:

• Direct launch from Bash:
  • process is a direct child of the login shell;
  • COLORTERM is unset;
  • submitted user prompts have a green highlight.
• Resumed session:
  • copilot --allow-all --remote --resume spawns a child Copilot process with --session-id;
  • the shell and parent Copilot process have COLORTERM unset;
  • the spawned child has COLORTERM=truecolor;
  • submitted user prompts have a gray highlight.

There is no repository-local Copilot setting or Git color configuration explaining the difference. copilot help config exposes only whole-theme presets and no prompt-background setting.

Affected version

GitHub Copilot CLI 1.0.76-3

The long-running resumed session was originally started on an earlier 1.0.76 build and survived CLI updates, but the current process/executable reports 1.0.76-3.

Steps to reproduce the behavior

1. Open a fresh WSL2 Bash shell in Windows Terminal.

2. Confirm the variable is absent:

   printenv COLORTERM
   

3. Launch Copilot directly:

   copilot --allow-all --remote
   

4. Submit a prompt and observe the user-message highlight.

5. In another fresh shell with COLORTERM still unset, resume a saved session:

   copilot --allow-all --remote --resume
   

6. Select a session, submit a prompt, and observe that the highlight color differs.

7. Inspect the processes:

   ps -eo pid,ppid,args | grep '[c]opilot'
   tr '\0' '\n' </proc/<copilot-pid>/environ | grep -E '^(TERM|COLORTERM|WT_SESSION)='
   

8. Observe that the resumed child has COLORTERM=truecolor, while its parent Copilot process and launching Bash shell do not.

Expected behavior

Copilot CLI should preserve the launching terminal's color-capability environment consistently across direct, resumed, and restarted sessions.

A resumed child process should not inject or change COLORTERM relative to its launching shell/parent. With the same terminal and theme setting, submitted user prompts should render with the same highlight colors.

Additional context

• OS: WSL2 Linux, x86_64
• Terminal: Windows Terminal
• Shell: Bash login shell
• TERM=xterm-256color in both sessions
• Same Windows Terminal profile ID in both sessions
• User setting: "theme": "github"
• No repository-local theme/config override found
• The only observed discriminator was COLORTERM=truecolor on the resumed child

Related open issues:

• #3591 — user prompt visual distinction/configuration
• #4292 — truecolor-related rendering differences
• #4212 — prompt/highlight rendering differs by terminal context

This report is narrower: it concerns Copilot CLI's resumed-session process launch changing COLORTERM, producing different rendering without any terminal, user, repository, or theme-setting change.

在 WSL2 Bash 中重现直接启动和恢复启动，然后按照描述使用 ps 和 /proc//environ 检查恢复的子进程。跟踪带有 --session-id 的子进程是如何启动的，并确保它保留启动它的 shell 的 COLORTERM 状态；当直接、恢复和重新启动的会话在相同的终端设置下呈现相同的提示符高亮时，即表示完成。