[BUG] 2.1.268: statusLine command is never invoked when cwd is a git repo (works in a non-git cwd) — regression from 2.1.267

Summary

On 2.1.268 the configured statusLine command is never spawned when the session's cwd is inside a git repository. The status line area just stays empty — no error, no stale text, nothing in --debug.

The same binary, same settings, same script, launched with cwd = $HOME (not a git repo) runs the command normally and renders it. A concurrent session still running 2.1.267 inside a git repo keeps invoking it every few seconds, so this looks like a regression introduced in 2.1.268.

Environment

• Claude Code 2.1.268 (native installer, ~/.local/share/claude/versions/2.1.268)
• macOS (Darwin 25.5.0), iTerm2 3.6.11, TERM=xterm-256color
• ~/.claude/settings.json:

``json
"statusLine": { "type": "command", "command": "bash \"$HOME/.claude/statusline.sh\"" },
"tui": "fullscreen"
``

• launched as claude --dangerously-skip-permissions

How it was measured

I added one line at the very top of the status line script, immediately after input=$(cat), so that every spawn is recorded independently of what the script prints:

input=$(cat)
printf '%s %s\n' "$(date +%T)" "$(printf '%s' "$input" | jq -r '.session_id // "?"')" >> /tmp/statusline-sessions.log

Observed

Four sessions, same user settings, same script, same machine, running at the same time:

| session | version | cwd | spawns recorded |
|---|---|---|---|
| A | 2.1.268 | $HOME — not a git repo | yes, renders correctly |
| B | 2.1.268 | a normal git clone | none |
| C | 2.1.268 | a git worktree of that clone | none |
| D | 2.1.267 | a git repo | yes, continuously |

B and C stayed at zero spawns over several minutes of active use (tool calls, assistant messages, shift+tab permission-mode cycling — the last one should force a refresh).

Additional data points

• claude --debug in an affected session: the debug log contains no statusline-related line at all — not even Skipping StatusLine command execution - workspace trust not accepted. So it does not appear to be the workspace-trust skip path.
• Workspace trust is not the discriminator either: in ~/.claude.json the working cwd has hasTrustDialogAccepted: false, one broken cwd has true, and another broken cwd has no projects entry at all.
• The script itself is fine: run by hand in the affected cwd with a real captured stdin JSON it exits 0 in ~0.3 s and prints the expected line.
• Fullscreen TUI is not a sufficient cause on its own — session A above also ran with "tui": "fullscreen" and worked.

Expected

The statusLine command is invoked regardless of whether cwd is inside a git repository.

Not yet isolated

Both broken cwds are git repos and carry a project-level .claude/settings.json (with hooks); the working cwd is $HOME, which has neither. So "cwd is a git repo" vs "project-level settings/hooks present" is still confounded. Happy to run whatever narrowing test would help.