[BUG] Custom statusLine never renders when `tui` is set to `fullscreen` (macOS, 2.1.170)

Open 💬 0 comments Opened Jul 10, 2026 by rodrigosoldi

Preflight Checklist

  • [x] I have searched existing issues. Closest matches are distinct — see "Related issues" below.
  • [x] This is a single bug report.
  • [x] Repro confirmed in both directions (toggling fullscreen on and off).

Summary

Setting "tui": "fullscreen" in settings.json silently suppresses a custom statusLine. It never renders. Switching to "tui": "default" makes it appear immediately, with no other changes — and toggling back to fullscreen makes it disappear again.

Nothing is logged and no error is surfaced. The status line row simply never appears, which makes this look like a broken statusLine script rather than a TUI-mode interaction. I spent a while debugging the script before suspecting tui.

Environment

  • Claude Code version: 2.1.170
  • OS: macOS (Darwin 25.5.0), Apple Silicon
  • Shell: zsh
  • Terminal: VS Code integrated terminal

Expected behavior

The statusLine command runs and its stdout renders in the row above the footer, in both "tui": "default" and "tui": "fullscreen".

Actual behavior

In fullscreen, the status line is never rendered. In default, it renders correctly.

Steps to reproduce

  1. Create an executable status line script that prints to stdout and exits 0, e.g. ~/.claude/statusline-command.sh:

``bash
#!/usr/bin/env bash
echo "hello from statusline"
``

  1. Add both keys to ~/.claude/settings.json:

``json
{
"statusLine": {
"type": "command",
"command": "bash /Users/me/.claude/statusline-command.sh"
},
"tui": "fullscreen"
}
``

  1. Start claude in a terminal. Observed: no status line is rendered at all.
  1. In the same session, run /tui default. Observed: the status line appears immediately.
  1. Run /tui fullscreen again. Observed: the status line disappears again.

Steps 4 and 5 were both executed and confirmed — the behavior toggles deterministically with the tui value.

What I ruled out

I verified each documented failure mode from https://code.claude.com/docs/en/statusline.md before filing:

  • settings.json is valid JSON; statusLine is defined exactly once.
  • No managed-settings.json at /Library/Application Support/ClaudeCode/ or /etc/claude-code/, so nothing overrides user settings.
  • Other keys in the same settings.json (model, effortLevel, hooks, enabledPlugins) are honored, so the file is loaded and parsed.
  • The script is executable, exits 0, and produces non-empty stdout when invoked manually with a representative JSON payload on stdin.
  • The script is fast (plain shell, no network calls), so this is not the slow-script cancellation path.
  • disableAllHooks is not set anywhere.
  • hasTrustDialogAccepted is true for the project directory.
  • Restarting claude does not help while tui is fullscreen.

The only variable that changes the outcome is the value of tui.

Documentation gap

Neither page documents this interaction:

So it is unclear whether this is an intentional limitation of the alternate-screen renderer or a bug.

Related issues (believed distinct)

  • #72276 — statusLine command never spawned on macOS. Distinct: that reporter explicitly reproduced in both TUI modes, and instrumented the command to prove it is never invoked. Here, default works fine.
  • #76051 — status line renders at startup then disappears after an assistant response and never redraws (Windows). Distinct: that is a redraw bug independent of tui, and the reporter explicitly ruled out CLAUDE_CODE_NO_FLICKER. Here it never renders at all under fullscreen, and always renders under default.
  • #68742 — fullscreen TUI statusline vertical desync under nested/parallel subagent load (WSL2). Related area, but that is a misalignment under load rather than total suppression.

Requested outcome

Either:

  1. Render statusLine in fullscreen mode, or
  2. If the alternate-screen renderer genuinely cannot support it, document the incompatibility on both pages and emit a one-time warning when statusLine is configured while tui is fullscreen.

The silent failure is the worst part. The natural first assumption is that the status line script is broken, so debugging time goes entirely into the wrong place.

Minor side note

/tui default persists the value to ~/.claude/settings.json rather than applying only to the current session. That is arguably fine, but it is not stated on the fullscreen docs page, and it means a user "just testing" the toggle silently changes their saved config.

View original on GitHub ↗