Project layers in the rail reflect knobs.cc's launch dir, not the user's claude session #12

Problem

The project and project_local rows in the precedence rail are scoped to knobs.cc's own current working directory — wherever npm run tauri dev (or the built bundle) was launched from — not to a user-specified Claude Code session.

In practice this means:

• If a developer launches knobs.cc from ~/Projects/knobs.cc/, the project layers read ~/Projects/knobs.cc/.claude/settings.json and settings.local.json. Those are config for this repo, not for any claude session the user actually cares about inspecting.
• The current rail copy (the path string) reads as a real, authoritative project entry. A user who clicks a key and sees the project layer marked as winning might trust a value that came from an unrelated repo.
• The two file-based project layers are the only ones in the precedence model that are inherently relative to where claude is running. managed, env, user, and default are global from any caller's perspective. cli is per-invocation but already greys out (tracked in Read another running claude process's argv + env (the "runtime introspection" layer) #11) precisely because it can't be answered without a process target.

Same axis as #11, applied to "where is claude running?" instead of "what argv/env does claude have?". Both questions need the app to know which claude session it's grounding itself in.

Short-term: grey out the rail rows

For now, treat project and project_local like cli — render them at reduced opacity in PrecedenceRail so users don't trust a project value that came from an unrelated dir.

UI scope (shipping with this issue's opening commit):

• PrecedenceRail rows for project and project_local get disabled: true (opacity-45).
• No backend change: read_settings_layers keeps reading the files; SettingsList rows, SourceBadge, presence cells, and KeyDrawer are untouched.

That's a stopgap, not a fix.

Longer-term: ground project visibility in a chosen claude session

A few framings, none committed:

1. Attach mode (parallel to Read another running claude process's argv + env (the "runtime introspection" layer) #11's Proposal A). Enumerate running claude processes, let the user pick one, use its CWD to resolve project/project_local. Pairs naturally with Read another running claude process's argv + env (the "runtime introspection" layer) #11 — same sysinfo-based discovery layer.
2. Launch mode (instrumentation harness). knobs.cc spawns claude itself with a chosen directory and CLI args. Because we exec'd the process we know its CWD, argv, and starting env without scraping /proc or sysctl. Doesn't help users with an already-running claude.
3. Path picker mode (no claude dependency). Drop the "match a running claude" framing entirely and just ask the user "which directory should I treat as your claude project?" — falls back to the current CWD if unset. Cheapest to implement; bypasses the discovery + permissions work in Read another running claude process's argv + env (the "runtime introspection" layer) #11.
4. Some combination. e.g. ship (3) immediately to unblock the rail, then layer (1) or (2) on top once Read another running claude process's argv + env (the "runtime introspection" layer) #11 lands so the picker auto-fills from a chosen process.

Open design questions

• Is project visibility one feature with Read another running claude process's argv + env (the "runtime introspection" layer) #11, or a sister feature? Same OS-level problem and same UX (process picker), but path picker (proposal 3) is a viable path that doesn't depend on Read another running claude process's argv + env (the "runtime introspection" layer) #11 at all.
• Do project/project_local follow whichever claude session is selected, or is the path a separate user choice that can diverge from the running process? Both are defensible.
• Should the rail show the chosen path in a dedicated header strip ("scoped to: /Users/sam/proj/foo") so users always know what context they're inspecting?

Related

• Read another running claude process's argv + env (the "runtime introspection" layer) #11 — Runtime introspection (argv + env) for a running claude process. Same axis; the picker/discovery work overlaps. Path picker (proposal 3) is independent of Read another running claude process's argv + env (the "runtime introspection" layer) #11; attach mode (proposal 1) shares its plumbing.
• src/components/inspector/PrecedenceRail.tsx — where the greyout lands.
• src-tauri/src/settings.rs — read_settings_layers reads project files relative to std::env::current_dir() today; needs a session-relative root for any of the long-term proposals.