Branch dirty indicator triggers on untracked files (false positive)

[cwedgwood]

The branch indicator in the TUI header shows a dirty marker (*) when the repository contains untracked files, even though the working tree is clean (no modified, staged, or deleted tracked files). Untracked files should not cause the dirty indicator — git does not consider them part of the working tree state.

Note: This bug was identified and reproduced by a copilot-cli agent (Claude Opus 4.6) during an interactive session with user @cwedgwood. The reproduction steps below were performed by the agent with the user observing and reporting the header output.

Affected version

GitHub Copilot CLI 1.0.6-2

Steps to reproduce the behavior

# 1. Create a clean repo
mkdir /tmp/dirty-test && cd /tmp/dirty-test
git init && echo "hello" > tracked.txt && git add tracked.txt && git commit -m "init"

# 2. Start copilot — header shows: /tmp/dirty-test [⎇ master]  ✓ correct

# 3. Add an untracked file (do NOT git add it)
echo "untracked" > untracked.txt

# 4. Observe header now shows: /tmp/dirty-test [⎇ master*]  ✗ false positive
#    git status shows only: ?? untracked.txt
#    No tracked files are modified.

# 5. Remove the untracked file
rm untracked.txt

# 6. Header returns to: /tmp/dirty-test [⎇ master]  ✓ correct

Additional observations from testing:

State	git status --short	Header	Correct?
Clean tree, no untracked	(empty)	master	✓
Modified tracked file	M tracked.txt	master*	✓
Clean tree + untracked file	?? untracked.txt	master*	✗
Clean tree + gitignored file	(empty)	master	✓
Clean tree + untracked + gitignored	?? untracked.txt	master*	✗

Expected behavior

The dirty indicator (*) should only appear when tracked files have modifications (staged, unstaged, or deleted). Untracked files (?? in git status --porcelain) should not trigger it. This matches the behavior of git prompts like __git_ps1 which distinguish % (untracked) from * (dirty).

Additional context

• OS: Linux 6.12.74 x86_64
• Shell: bash
• Terminal: xterm-color (containerized sandbox)
• Likely root cause: the dirty check uses git status --porcelain (or equivalent) without filtering out ?? entries. Fix would be to use git diff --quiet HEAD for dirty detection, or filter porcelain output to exclude ?? lines.