Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix Feature request: per-project scoped statusLine and notifications [3 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#56414•Fetched 2026-05-06 06:28:42
View on GitHub
Comments
3
Participants
2
Timeline
6
Reactions
0
Author
ApolloZhangOnGithubApolloZhangOnGithub
Participants
ApolloZhangOnGithubApolloZhangOnGithubgithub-actions[bot]github-actions[bot]
Timeline (top)
commented ×3labeled ×2closed ×1

Claude Code's statusLine in settings.json is a global config. When users set up a custom status line script that shows project-specific info (e.g. unread message counts, build status), it displays across all projects — even where it's irrelevant.

Root Cause

Claude Code's statusLine in settings.json is a global config. When users set up a custom status line script that shows project-specific info (e.g. unread message counts, build status), it displays across all projects — even where it's irrelevant.

Fix Action

Fix / Workaround

Users working across multiple projects shouldn't see status info from unrelated projects. Currently the workaround is hardcoding path checks in the shell script, which is fragile.

RAW_BUFFERClick to expand / collapse

Context

Claude Code's statusLine in settings.json is a global config. When users set up a custom status line script that shows project-specific info (e.g. unread message counts, build status), it displays across all projects — even where it's irrelevant.

Proposal

Support per-project statusLine configuration, similar to how .claude/settings.json already provides per-project hook and permission settings. This would allow:

  1. Project-level statusLine in .claude/settings.json (per-project) that overrides or extends the global one.
  2. Pass project root path as part of the JSON input to statusLine scripts, so scripts can self-filter without hardcoding paths.

Option 2 is the minimal change — the statusLine script already receives JSON via stdin with workspace.current_dir, but having an explicit workspace.project_root would make project-scoping trivial.

Why

Users working across multiple projects shouldn't see status info from unrelated projects. Currently the workaround is hardcoding path checks in the shell script, which is fragile.

Note: this is a genuine feature request. A previous issue (#56412) was filed by mistake about a misconfigured script — this one is about the actual product gap behind it.

extent analysis

TL;DR

To address the issue, consider adding a project-level statusLine configuration in .claude/settings.json that overrides the global setting.

Guidance

  • Introduce a project_root key in the JSON input to statusLine scripts, allowing them to self-filter based on the project.
  • Update the statusLine script to use the project_root key for filtering, rather than relying on hardcoded path checks.
  • Modify the global statusLine configuration to accept an array of project-specific configurations, enabling per-project overrides.
  • Test the updated configuration with multiple projects to ensure the status line displays relevant information for each project.

Example

{
  "statusLine": {
    "global": "...",
    "projects": {
      "/path/to/project1": "...",
      "/path/to/project2": "..."
    }
  }
}

Notes

The proposed solution assumes that the statusLine script can be updated to handle the new project_root key and that the .claude/settings.json file can be modified to include project-specific configurations.

Recommendation

Apply workaround by passing the project root path as part of the JSON input to statusLine scripts, allowing them to self-filter without hardcoding paths. This approach is the minimal change required to address the issue.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#orchestration issue#cache issue#memory leak#API versioning#request timeout

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix Feature request: per-project scoped statusLine and notifications [3 comments, 2 participants]