statusLine command never invoked on macOS (2.1.195, Homebrew native binary) — config valid, command works manually, zero spawns

Resolved 💬 1 comment Opened Jun 29, 2026 by lheureuxe13 Closed Jun 30, 2026

statusLine command is never invoked on macOS (2.1.195, Homebrew native binary) — config valid, command works when run manually, zero spawns confirmed via logging

Summary

A custom statusLine command configured in ~/.claude/settings.json is never executed by Claude Code. The status line is completely absent from the UI. This is not a rendering/layout glitch — the configured command is never spawned at all. The same setup worked on an earlier version; it stopped after updating to a build that includes the fullscreen TUI.

Environment

  • Claude Code version: 2.1.195
  • Install method: Homebrew cask claude-code@latest (native/standalone binary at /opt/homebrew/Caskroom/claude-code@latest/2.1.195/claude, symlinked as /opt/homebrew/bin/claude)
  • OS: macOS 26.5.1 (Darwin 25.5.0)
  • Shell: zsh
  • Last known-good version: earlier release (reporter recalls ~2.1.191); broke after updating to a version that introduced the fullscreen TUI.

Expected behavior

The statusLine.command is executed (per the status line docs: on assistant message completion, after /compact, on permission/vim-mode change, and at launch), its stdout is rendered as the status line in both "tui": "default" and "tui": "fullscreen" modes.

Actual behavior

The command is never spawned. The status line never appears — not at launch (where it previously appeared immediately), not after a completed assistant turn, in neither TUI mode.

Proof the command is never invoked

I instrumented the configured command so that its very first statement appends a timestamp to a log file, before anything that could fail:

// ~/.claude/settings.json
"statusLine": {
  "type": "command",
  "command": "date '+%Y-%m-%dT%H:%M:%S invoked' >> \"$HOME/.claude/statusline-debug.log\" 2>&1; <rest of status line script>"
}

After multiple fresh launches and completed assistant turns, ~/.claude/statusline-debug.log remains empty. Because the log write is the first thing in the command, an empty log means the command process was never started by Claude Code (it is not a case of the command running and erroring).

Steps to reproduce

  1. On macOS, install Claude Code 2.1.195 via the Homebrew cask (brew install --cask claude-code@latest).
  2. Add a minimal statusLine to ~/.claude/settings.json:

``json
"statusLine": {
"type": "command",
"command": "date >> \"$HOME/.claude/sl-test.log\"; cat | jq -r '.model.display_name'"
}
``

  1. Fully quit all Claude Code instances, then launch a brand-new (non-resumed) session and let one assistant turn complete.
  2. Observe: no status line appears, and ~/.claude/sl-test.log is never created/written → the command was never invoked.

What I have ruled out (this is not a misconfiguration)

  • Config is structurally valid: statusLine is exactly { "type": "command", "command": "…" } with no unknown/extra keys. jq parses settings.json without error.
  • settings.json is being read: other settings in the same file (model, enabled plugins, effortLevel) are honored — so the file is loaded and parsed; only statusLine is ignored.
  • The command itself works: piping representative JSON to the command by hand produces correct, colored output with exit code 0 (jq is installed and on PATH).
  • Not a TUI-mode issue: reproduced identically with "tui": "default" and "tui": "fullscreen".
  • Not the alternate-screen env var: removing CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1 from env made no difference.
  • No hidden disable flag: no status-line-related flag anywhere in ~/.claude.json.
  • Not stale/multi-instance state: reproduced after quitting all instances and launching a single fresh session; on-disk config confirmed correct at test time.

Additional notes

  • The reporter prefers "tui": "default" (classic renderer / native scrollback), but the bug is present in both renderers.
  • Appears to be a regression on macOS in the recent (fullscreen-TUI-era) releases; may be related to previously reported "statusLine command not executed on macOS" reports — maintainers can confirm/dedupe.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗