[Bug] Custom statusLine command from settings.json not being executed

Found 1 possible duplicate issue:

1. https://github.com/anthropics/claude-code/issues/12345

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

I'm talking about the status line at the bottom of Claude Code, which was working just fine until 2.0.62

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

Yes, this is still happening .. Cannot get the statusline which shows at the bottom (usually)

Still an issue for me on 2.1.12

Still an issue for me on 2.1.20

still an issue on 2.1.37

fix it fast please

This seems to be happening when Claude cannot detect the correct shell path:

❯ What's the shell path you use to run scripts?

⏺ Based on the environment info, your shell is zsh at /bin/zsh.

However, my default shell is another Zsh version installed using MacPorts:

$ echo $SHELL
/opt/local/bin/zsh

In my case I fixed it by setting CLAUDE_CODE_SHELL variable in my ~/.claude/settings.json:

{
...
    "env": {
        "CLAUDE_CODE_SHELL": "/opt/local/bin/zsh"
    },
...
}

However the statusline only displays after the first prompt response, and is only updated when a response is displayed

Same issue on v2.1.49, Windows Terminal

Windows PowerShell the same issue.

Still broken on v2.1.56 (macOS Darwin 25.2.0). Script is executable, runs correctly when invoked manually, settings.json config is valid — command is simply never executed by Claude Code.

Same issue on 2.1.56 (Windows Terminal)

Windows Native (Git Bash) - Still broken in v2.1.62

Environment:

• OS: Windows 11
• Shell: Git Bash (MSYS2)
• Claude Code: v2.1.62
• Terminal: Windows Terminal / PowerShell 7

Reproduction:
Configured statusLine in ~/.claude/settings.json with various approaches — none work:

// Attempt 1: .cmd wrapper
"command": "C:\Users\primus\.claude\statusline-wrapper.cmd"

// Attempt 2: pwsh inline
"command": "pwsh -NoProfile -File C:\Users\primus\.claude\statusline-command.ps1"

// Attempt 3: full path
"command": "C:\Program Files\PowerShell\7\pwsh.exe -NoProfile -File C:\Users\primus\.claude\statusline-command.ps1"

Debug result: Added a log-writing test script — log file is never created, confirming the command is never invoked at all.

Note: The script works perfectly when run manually. This is purely a Claude Code invocation issue on Windows Native (non-WSL).

I ran into this too and eventually got it working again. In my case the root cause was IS_DEMO=1.

I was using IS_DEMO=1 (env var) to hide my account email when screen sharing / taking screenshots. I'd seen it mentioned online as the only current way to do this, but I couldn't find a clear description of all the side effects, one of which turned out to be crucial here.

What's happening

On first launch in a project, Claude Code normally asks whether you trust the project. When you accept, it writes an entry into ~/.claude.json under the projects list with:

• hasTrustDialogAccepted: true (defaults to false)

With IS_DEMO=1, the trust prompt never appears, so hasTrustDialogAccepted stays false indefinitely. That seems to disable (or partially disable) features that could involve untrusted code execution, and it also appears to affect things like status lines.

What I observed

• Without IS_DEMO: trust prompt appears = everything works.
• With IS_DEMO: no trust prompt = things break.
• With IS_DEMO=1 and hasTrustDialogAccepted=true: everything works.

TL;DR / Fix

If you have IS_DEMO=1 set, you won't see the trust question on startup, and that can silently break features (including status lines). Fix is either:

1. remove IS_DEMO, or
2. manually set the project’s hasTrustDialogAccepted to true in ~/.claude.json.

Note: trust is hierarchical, you can set hasTrustDialogAccepted=true on a parent folder (e.g. /path/to/projects-folder) to cover everything beneath it. Obviously only do that if you're comfortable granting blanket trust to code in that folder.

Hope this saves someone else some time, this took me a while to track down!

Still broken on v2.1.107 — Windows 11 / Git Bash / Windows Terminal

Confirming this is still not fixed. Same symptom as @vimholic's report above.

Environment:

• OS: Windows 11 Pro
• Shell: Git Bash (C:\Program Files\Git\usr\bin\bash.exe, MSYS2)
• Terminal: Windows Terminal (WT_SESSION is set)
• Claude Code: v2.1.107
• Python: 3.14.4 at C:\Python314\python.exe

Config in ~/.claude/settings.json:

"statusLine": {
"type": "command",
"command": "python C:\\Users\\xyz\\.claude\\statusline.py"
}
Diagnostic: Added a debug logger to the statusline script that writes raw stdin to a log file on every invocation. After full
Claude Code restart in a fresh terminal and several user prompts, the log file is never created — confirming the script is not
being invoked at all. The script itself works correctly when called manually.

Workarounds tried (all unsuccessful):

• Set "env": { "CLAUDE_CODE_SHELL": "C:\\Program Files\\Git\\usr\\bin\\bash.exe" } per @jleroy's suggestion — no change, script

still not called.

• Verified hasTrustDialogAccepted: true for the project in ~/.claude.json per @rraywhite's suggestion — already true, no change.
• IS_DEMO env var is not set.

Affected since at least v2.1.62 (@vimholic) → still present in v2.1.107.

Still happening

Still broken on v2.1.107 — Windows 11 / Git Bash / Windows Terminal Confirming this is still not fixed. Same symptom as @vimholic's report above. Environment: OS: Windows 11 Pro Shell: Git Bash (C:\Program Files\Git\usr\bin\bash.exe, MSYS2) Terminal: Windows Terminal (WT_SESSION is set) Claude Code: v2.1.107 Python: 3.14.4 at C:\Python314\python.exe Config in ~/.claude/settings.json: "statusLine": { "type": "command", "command": "python C:\Users\xyz\.claude\statusline.py" } Diagnostic: Added a debug logger to the statusline script that writes raw stdin to a log file on every invocation. After full Claude Code restart in a fresh terminal and several user prompts, the log file is never created — confirming the script is not being invoked at all. The script itself works correctly when called manually. Workarounds tried (all unsuccessful): Set "env": { "CLAUDE_CODE_SHELL": "C:\Program Files\Git\usr\bin\bash.exe" } per @jleroy's suggestion — no change, script still not called. Verified hasTrustDialogAccepted: true for the project in ~/.claude.json per @rraywhite's suggestion — already true, no change. IS_DEMO env var is not set. Affected since at least v2.1.62 (@vimholic) → still present in v2.1.107.

Can confirm, still happening.

Thanks @xInfinitYz — confirming the same symptom on macOS with zsh on my side, so this is not Windows/Git-Bash-specific:

• macOS 15.x, zsh, Claude Code v2.1.101
• statusLine command: ~/.claude/bin/statusline.sh (shebang #!/bin/bash, chmod +x verified, manual invocation works and emits JSON to stdout)
• stdin-logging wrapper at the top of the script never writes to its log file after a fresh session start → the statusLine command is not being invoked at all.

Workarounds tried (same symptom as reported above):

• Absolute paths instead of ~: no change
• "type": "command" explicit: no change
• hasTrustDialogAccepted: true verified in ~/.claude.json: already true

Cross-platform signal suggests the bug isn't tied to shell discovery — the statusLine invocation itself seems to not happen, regardless of which shell would've been resolved.

_[Comment redacted – the root cause of my issue is different than this bug. Company-managed config, not Claude Code itself.]_

Same issue here, 2.1.139, Windows 11.

Running claude --debug consistently shows this warning in the debug file:

2026-05-20T12:00:22.426Z [WARN] StatusLine [bash ~/.claude/statusline.sh] completed with status 1

No matter what I try (bash, powershell, node, cmd, direct script invocation) the command is never invoked and the "command" value in the settings.json is written in the log line.

I had the same problem – no statusline whatever I did.
Using claude --debug I found this error in the log:

2026-06-12T09:55:30.567Z [DEBUG] StatusLine [powershell -NoProfile -File C:\Users\MYUSERNAME\.claude\statusline.ps1] stderr: Das Argument "C:UsersMYUSERNAME.claudestatusline.ps1" f�r den -File-Parameter ist nicht vorhanden. Geben Sie als Argument f�r den -File-Parameter den Pfad zu einer vorhandenen .ps1-Datei an.

The agent simply did not find my .PS1 statusline script.
In C:\Users\MYUSERNAME\.claude\settings.json I found:

"statusLine": {
"type": "command",
"command": "powershell -NoProfile -File C:\\Users\\MYUSERNAME\\.claude\\statusline.ps1"
}

Changing the backslashes to forward slashes solved the problem!

"command": "powershell -NoProfile -File C:/Users/MYUSERNAME/.claude/statusline.ps1"

BTW: That defective settings.json line was written by Claude Code itself, and it tried heavily to understand why it did not work, before telling me that this must be a bug in the current agent version. ;D