feat(install): add --project flag for per-project MCP installation

[halindrome]

Summary

• Adds --project [path] flag to install and uninstall subcommands
• When --project is given, MCP config is written into {path}/.claude/ (or cwd if no path follows the flag) instead of the global ~/.claude/
• Adds cbm_claude_config_dir() helper that checks CLAUDE_CONFIG_DIR env var first, then falls back to ~/.claude — used by install, uninstall, and update

What was changed

• src/cli/cli.c — claude_config_dir() helper (exported as cbm_claude_config_dir), --project flag parsing in cbm_cmd_install and cbm_cmd_uninstall, Claude Code paths now built via claude_dir variable; cbm_cmd_update also uses cbm_claude_config_dir
• src/cli/cli.h — cbm_claude_config_dir declaration; #include <stddef.h> for size_t
• tests/test_cli.c — 3 new tests: cli_claude_config_dir_default, cli_claude_config_dir_env_override, cli_project_install_targets_project_claude_dir

Test plan

• build/c/test-runner — all 2040 tests pass
• New tests verify CLAUDE_CONFIG_DIR env var override
• New tests verify --project path construction targets {path}/.claude/

C port of the Go --project flag (same semantics as the Go implementation).

🤖 Generated with Claude Code

[halindrome]

QA Round 1

QA Round 1 — PR #74 (feat/c-project-install)
Model used: Claude Opus 4.6

FINDINGS:

[Finding 1] --project still runs all global agent installs (Codex, Gemini, Zed, etc.)
- What was tested: Whether --project scopes the install to only Claude Code project-local config.
- Expected vs actual: Steps 5-12 still install configs for Codex (~/.codex/), Gemini (~/.gemini/), Zed, OpenCode, Antigravity, Aider, and KiloCode into their global home-directory locations. Only Claude Code paths (Step 4) are redirected to the project dir. Users expecting a project-local install get unexpected global side effects.
- Severity: major
- Confirmed vs hypothetical: Confirmed

[Finding 2] cbm_cmd_update does not support --project
- What was tested: Whether `update` respects a project-local install.
- Expected vs actual: cbm_cmd_update has no --project parsing and always targets ~/.claude or CLAUDE_CONFIG_DIR. After a project-local install, running `update` reinstalls skills globally, leaving the project-local skills stale with no way to refresh them.
- Severity: major
- Confirmed vs hypothetical: Confirmed

[Finding 3] CLAUDE_CONFIG_DIR / --project path with trailing slash causes double-slash in constructed paths
- What was tested: Path construction when env var or --project arg has a trailing slash.
- Expected vs actual: cbm_claude_config_dir() copies CLAUDE_CONFIG_DIR verbatim; downstream snprintf appends "/skills" etc., producing "//skills". Most POSIX systems tolerate this but it produces confusing output.
- Severity: minor
- Confirmed vs hypothetical: Confirmed

[Finding 4] --project with non-existent path proceeds without validation
- What was tested: Error handling when project path does not exist.
- Expected vs actual: No stat() or access() check before use; mkdir may fail silently deep in the install chain with no clear user-facing error.
- Severity: minor
- Confirmed vs hypothetical: Confirmed

[Finding 5] --project still places binary in ~/.local/bin and modifies shell RC
- What was tested: Whether global binary placement and PATH modification are skipped for project installs.
- Expected vs actual: Step 2 (self_path to ~/.local/bin) and Step 12 (cbm_ensure_path / shell RC) have no has_project guard.
- Severity: minor
- Confirmed vs hypothetical: Confirmed

[Finding 6] Uninstall --project still removes global agent configs
- What was tested: Symmetry of uninstall --project with install --project.
- Expected vs actual: Consistent with install (same scoping issue), but means uninstall --project has global side effects matching the install asymmetry.
- Severity: minor
- Confirmed vs hypothetical: Confirmed

[Finding 7] Buffer size (1024) for path construction with long project paths
- What was tested: Path truncation for very long project paths.
- Expected vs actual: snprintf return value unchecked; silent truncation possible for paths near 1024 chars.
- Severity: minor
- Confirmed vs hypothetical: Hypothetical

[Finding 8] --project flag not in --help output
- What was tested: Whether usage/help strings were updated.
- Expected vs actual: No help text changes in the diff. Users can't discover --project from --help.
- Severity: minor
- Confirmed vs hypothetical: Confirmed

[Finding 9] cbm_claude_config_dir() never returns NULL despite the doc saying it can
- What was tested: NULL return path.
- Expected vs actual: Always returns buf; doc comment is inaccurate. If home is NULL and CLAUDE_CONFIG_DIR is unset, undefined behavior from NULL snprintf arg.
- Severity: minor
- Confirmed vs hypothetical: Confirmed

[Finding 10] Test coverage gaps
- What was tested: Which --project code paths are covered by the 3 new tests.
- Expected vs actual: Missing: --project + --dry-run, --project + --force, trailing slash, --project without path (getcwd), CLAUDE_CONFIG_DIR vs --project precedence, uninstall --project.
- Severity: minor
- Confirmed vs hypothetical: Confirmed

[Finding 11] --project=path (equals-separated) syntax not supported
- What was tested: Argument parsing for --project=/foo/bar.
- Expected vs actual: Only space-separated supported. Consistent with --dry-run/--force; noted for completeness.
- Severity: minor
- Confirmed vs hypothetical: Confirmed

SUMMARY: 0 critical, 2 major, 9 minor findings.

[halindrome]

QA Round 1 — Fixes Applied

Addressed all confirmed findings from the Opus QA review. Commit: 25cac80

Fixed

[Major] --project runs global agent installs — steps 5–12 in cbm_cmd_install (Codex CLI, Gemini CLI, Zed, OpenCode, Antigravity, Aider, KiloCode, PATH setup) are now wrapped in if (!has_project). When --project is used, only step 4 (Claude Code — skills + MCP config + hooks into {project}/.claude/) executes. The "Install complete" message is printed outside the guard and omits the "source ~/.bashrc" line when --project is in use.

[Major] cbm_cmd_update lacks --project support — added --project [path] flag parsing to cbm_cmd_update. When set, step 6 (reinstall skills) also runs cbm_install_skills against {project_path}/.claude/skills so project-local skills are updated alongside global ones during a binary update.

[halindrome]

QA Round 2 — feat/c-project-install (#74)

Reviewed: src/cli/cli.c, src/cli/cli.h, tests/test_cli.c

---

[Major] cbm_cmd_uninstall is missing if (!has_project) guard for non-Claude agents

File: src/cli/cli.c, cbm_cmd_uninstall

In cbm_cmd_install, QA Round 1 correctly wrapped Steps 5-12 (Codex, Gemini, Zed, OpenCode, Antigravity, Aider, KiloCode, PATH) in if (!has_project) { ... }. However, the symmetric change was not applied to cbm_cmd_uninstall.

When a user runs cbm uninstall --project /some/project, the intent is to remove only the project-local Claude Code config (skills, .mcp.json, hooks from {project}/.claude/). Instead, the current code will also:

• Remove all global agent configs (Codex, Gemini, Zed, etc.) from $HOME
• Prompt to delete all indexes
• Delete the binary from ~/.local/bin

This is a data-loss scenario: a user cleaning up a project install would unintentionally nuke their entire global installation.

Fix: Wrap the Codex through KiloCode blocks and Steps 2-3 (index removal + binary removal) in if (!has_project) { ... }, matching the pattern used in cbm_cmd_install.

---

[Minor] cbm_claude_config_dir doc says "Returns NULL on error" but it never returns NULL

File: src/cli/cli.h and src/cli/cli.c

The header comment says "Returns buf on success, NULL on error." The implementation always calls snprintf into buf and returns buf — there is no error path that returns NULL. The doc is misleading and could cause callers to add unnecessary NULL checks.

Fix: Either update the doc to "Always returns buf" or add validation (e.g., return NULL if home is NULL and the env var is unset).

---

[Minor] --project "" (empty string argument) produces path "/.claude"

File: src/cli/cli.c, all three commands

The argument parser checks argv[i + 1][0] != '-' to decide if the next arg is a path. An empty string "" passes this check ('\0' != '-'), resulting in project_path = "" and claude_dir = "/.claude" — writing to the filesystem root.

This is unlikely in practice but trivially defensive to handle:

if (i + 1 < argc && argv[i + 1][0] != '-' && argv[i + 1][0] != '\0') {

---

[Nit] cbm_cmd_update --project always also updates global skills

File: src/cli/cli.c, cbm_cmd_update

When --project is provided, update reinstalls global skills unconditionally (Step 6) and then also updates project-local skills. This is arguably correct (update touches the binary, so global skills should match), but the behavior differs from install/uninstall where --project isolates the operation to the project scope. Worth documenting if intentional, or guarding with if (!has_project) for consistency.

---

[Nit] shell_rc initialization is correct but the style is unusual

File: src/cli/cli.c, cbm_cmd_install

const char *shell_rc = "";
if (!has_project) {
    ...
    shell_rc = cbm_detect_shell_rc(home);
    ...
} /* end if (!has_project) */

The variable is declared and initialized before the guarded block, reassigned inside it, then read after it. This works correctly. The if (!has_project && shell_rc[0]) post-block check is sound. No action needed — just confirming this is correct after QA Round 1.

---

Summary

Severity	Count
Critical	0
Major	1
Minor	2
Nit	2

Verdict: The install path looks solid after QA Round 1 fixes. The uninstall path has the same bug that was fixed in install — missing the if (!has_project) guard — and will cause unintended global uninstall when used with --project. This needs to be fixed before merge.

Tests cover cbm_claude_config_dir and project-scoped install path construction well. Consider adding a test that verifies --project uninstall does NOT touch global agent configs.

[halindrome]

QA Round 2 — Fixes Applied (commit 127d9da)

[Major] cbm_cmd_uninstall missing !has_project guard — wrapped the Codex/Gemini/Zed/OpenCode/Antigravity/Aider/KiloCode removal blocks, index removal (step 2), and binary removal (step 3) in if (!has_project). Running uninstall --project now only removes the project-local .claude/ skills and MCP config, exactly mirroring the scoping behavior of install --project.

[halindrome]

QA Round 3 — Final Review

Reviewer: Claude (Opus 4.6)
Branch: feat/c-project-install @ 127d9da
Scope: Full review of all --project flag logic in install, uninstall, and update commands.

Checklist

Item	Status
--project arg parsing (install)	OK — handles both --project <path> and --project (cwd fallback)
--project arg parsing (uninstall)	OK — same pattern
--project arg parsing (update)	OK — same pattern
claude_dir routing (install)	OK — {project_path}/.claude when has_project, else claude_config_dir()
claude_dir routing (uninstall)	OK — same pattern
agents.claude_code = true forced when has_project (install)	OK
agents.claude_code = true forced when has_project (uninstall)	OK
!has_project block in install (steps 5-12) opens and closes correctly	OK — opens at line ~2133, closes at line ~2279 with } /* end if (!has_project) */
!has_project block in uninstall (other agents, indexes, binary) opens and closes correctly	OK — opens at line ~2459, closes at line ~2517 with } /* end if (!has_project) */
shell_rc declared before the !has_project block (install)	OK — initialized to "" at line ~2131, assigned inside block, safely checked with shell_rc[0] after block
shell_rc usage after block (install)	OK — !has_project && shell_rc[0] guards the "source" hint; when has_project, shell_rc remains "" so the hint is suppressed
Update command: project skills updated alongside global skills	OK — cbm_install_skills called for project path when has_project
Tests for --project flag	OK — 3 tests in group G covering default dir, env override, and project-local targeting

Round 1 & 2 Fixes Verified

• Steps 5-12 (Codex, Gemini, Zed, OpenCode, Antigravity, Aider, KiloCode, PATH) correctly skipped in --project mode.
• Uninstall correctly skips other-agent removal, index deletion, and binary removal in --project mode.
• Update correctly parses --project and updates project-local skills.

Remaining Issues

None. No critical, major, or minor issues found.

Verdict

LGTM — Ready to merge.

All three rounds of QA are complete. The --project flag implementation is correct and consistent across install, uninstall, and update.

[DeusData]

We noticed this is the standalone version of the --project feature that's also bundled in PR #73. We've asked in #73 to split the extension mapping from the --project flag, so this PR is the right shape.

We'd like to think through the per-project install workflow a bit more before merging — specifically around binary path portability across team members and .claude/ gitignore conventions. We'll circle back on this one after #73's extension mapping feature lands. Thanks!