[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.

Reproduce direct and resumed launches in WSL2 Bash, then inspect the resumed child with ps and /proc//environ as described. Trace how the --session-id child is spawned and ensure it preserves the launching shell's COLORTERM state; done means direct, resumed, and restarted sessions render the same prompt highlight under the same terminal settings.