[FEATURE] add CLAUDE_PROJECT_DIR support to statusLine.command config

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

I have a project-scoped status line script committed in /project-root/.claude/statusline.sh and referenced in /project-root/.claude/settings.json like so:

{
  "statusLine": {
    "type": "command",
    "command": ".claude/statusline.sh"
  }
}

This works as expected when running claude from the /project-root/, but starting a Claude Code session from a sub directory, or when changing the cwd from the within Claude Code, the status line doesn't show / disappears (presumably because the relative path to the status line script is no longer valid).

Proposed Solution

The statusLine.command config should also support expansion of the $CLAUDE_PROJECT_DIR env var that was added to solve this same problem for hooks: https://github.com/anthropics/claude-code/issues/3583#issuecomment-3125746047

Arguments in favor:

• it's effectively the same issue as with hooks (something failing to run due to loss / change of context)
• both the status line and hooks are configured within the same file and use the same language in their definition (command), and therefore it's surprising that they don't work the same

Alternative Solutions

I know there's also CLAUDE_BASH_MAINTAIN_PROJECT_WORKING_DIR, and cd'ing back to the original directory after every bash command might help maintain the status line, but it didn't seem like an optimal solution when CLAUDE_PROJECT_DIR also exists.

Priority

Medium - Would be very helpful

Feature Category

Configuration and settings

Use Case Example

Example:

1. Configure a project-scoped status line script as described in the Problem Statement. It should reference the project's .claude/statusline.sh via a relative path.
2. Run claude from the project root; status line appears as expected.
3. Have claude change the cwd; status line disappears.

Additional Context

While it could be argued that status line preferences are likely to be different by user, we're using it to show / enforce some org-wide expectations (such as wether developers are using personal Claude subscritpions or Bedrock, which is preferred), and therefore first-class support for a project-scoped status line does make sense for us.