How should per-project install work? — follow-up to #309

[CorticalCode]

Was poking through the #309 branch and noticed your 25595a4 ("fix: sync hooks to installed settings target") — looks like the per-scope hook part is already mostly there. You added a targetPath argument to syncWidgetHooks so hooks land in whichever settings file the install targets, an isKnownCommand check so we don't write hook entries next to someone's custom non-ccstatusline statusLine, and a test pinning down "hooks follow the install, not whichever statusLine ends up active."

For the UI side: each scope (user-global, project-local) shows up as its own row in the menu, with the current state on the right — installed or not, refresh interval if set, plus a marker on whichever one Claude Code is actually using. Enter on a row drills into install / uninstall / reinstall / edit-refresh for that scope. Same idea as the existing flow where you pick a line and then edit its items — just at the scope level.

One thing I noticed while looking at this: buildCommand in src/utils/claude-settings.ts:251-255 always uses getConfigPath() no matter what. If I'm in project A's TUI and choose to install at user-global, project A's --config path ends up baked into the global command — which would then apply to every project. Making it scope-aware fixes that. Small change but worth doing in the same PR.

On hooks: with your targetPath / isKnownCommand work in place, Anthropic's docs say identical hook command strings dedupe automatically when merged across files. So if both scopes have the same install command, the hook fires once; if they differ (per-project --config), it fires once per scope, and a small fix on the Skills count side handles that cleanly. Open question — would you want me to build on top of 25595a4 on a follow-up branch, or rebase onto current main and redo the same hook-routing shape there?

[sirmalloc]

Sorry for the slow reply on this. I'm wondering if we need a global / project context switcher in the TUI. Default mode is global, installs are to ~/.claude/settings.json and settings in ~/.config/ccstatusline/settings.json like now, then a key-combo can switch to Project mode (with an option to copy the global config if there is no project settings in the current path), then the entire TUI is reflective of settings stored in .claude/ccstatusline.json and installs the hooks in ./claude/settings.local.json and make it force the --config .claude/ccstatusline.json parameter on the statusline install. If the TUI is launched in a project that has ccstatusline project-local settings, then we default to showing project mode.

That would allow two completely separate configs without just adding more main menu items. I think that's clean. Thoughts?

[CorticalCode]

No rush at all on the reply — I've got plenty on my end, so happy to pick this up whenever it suits you.

The switcher is cleaner than the per-scope rows I floated, and it settles the part I was least sure about (not piling more entries onto the install menu). 👍

On #58: @jackall3n's open PR already builds most of the config side — and uses the same .claude/ccstatusline.json:

• auto-detects a project config in the cwd (getSettingsConfiguration() keys off process.cwd()/.claude/ccstatusline.json), falling back to global — your "default to project mode if project settings exist"
• shows the active config path by the Main Menu title — your "marker on which is active"
• a "📁 Save Locally & Exit" that seeds a project config from global — your "copy global config"

Since this builds directly on his work, I'd love to loop @jackall3n back in — he proposed the original approach, and ideally we land the finished thing crediting all three (his config foundation, your hook-routing + design, and I'll take the glue/UI). Only if you're both happy with that.

What #58 doesn't have: the install/hook side (it doesn't touch claude-settings.ts/hooks.ts), and the switch is one-way (once a project file exists you're auto in project mode, no flip back to global).

The install/hook half is your 25595a4 (targetPath/isKnownCommand) plus a scope-aware buildCommand to force --config .claude/ccstatusline.json in project mode. One wrinkle: #58 predates the --config/initConfigPath system that's since landed, so the two "which settings file?" paths (cwd auto-detect vs explicit --config) need unifying — the forced project --config should resolve to the same file the TUI's project mode edits.

One thing worth deciding up front: the hooks/statusLine would live in .claude/settings.local.json, which Claude Code treats as personal/gitignored. So the config travels with the repo (.claude/ccstatusline.json is committable) but the install doesn't — a teammate cloning gets the config but installs ccstatusline themselves. Probably the right call, but if you'd want the install to travel too, the statusLine would go in committed .claude/settings.json instead. Which do you intend?

A few smaller things to pin down:

1. Project root = cwd? feat(settings): Add support for local/project settings #58 uses process.cwd() literally, so launching outside a project would create .claude/ wherever you are. Keep that, or detect a git root?
2. Bidirectional toggle + indicator: add a real global↔project flip (with a copy-from-global prompt when entering an empty project), keeping feat(settings): Add support for local/project settings #58's active-path indicator so it's never ambiguous which config you're editing vs which Claude is running here.
3. Hook double-fire: with a global hook and a project hook both present, Claude merges across files — worth confirming the dedup / skills-count handling covers two different --config commands.
4. Uninstall acts on the active mode's target only (leaving the .claude/ccstatusline.json data in place).

Happy to take the glue + UI here, building on #58 + 25595a4. If you and @jackall3n are good with it, do you want it based on the feat/settings-local-json branch (where 25595a4 lives), or rebased onto current main with the hook routing redone there?