Troubleshooting
Common issues and solutions when using Coding Friend.
Installation & Setup
cf install fails with permission error
Symptom: EACCES or permission denied when running cf install.
Fix: Make sure you have write access to the Claude Code config directories:
# Check ownership
ls -la ~/.claude/
# Fix if needed
chmod -R u+rw ~/.claude/
If you installed the CLI globally with sudo, reinstall without it:
npm install -g coding-friend-cli
cf install says "Claude Code CLI not found"
Symptom: The installer can't detect the claude CLI binary.
Fix: Ensure Claude Code is installed and accessible in your PATH:
which claude # Should show a path
claude --version
If claude is installed but not in PATH, restart your terminal or add its location to your shell profile.
Hooks not firing after install
Symptom: You ran cf install successfully but skills don't auto-invoke and auto-approve doesn't work.
Cause: Hooks are registered in Claude Code's settings files. If the settings file was overwritten or the hook paths are stale, they won't fire.
Fix:
- Check that hooks are registered:
cat ~/.claude/settings.json | grep -A2 "hooks"
- Re-run install to refresh hook paths:
cf install --user # or --project for project-level
- Restart Claude Code after reinstalling.
Auto-Approve
Auto-approve blocks a tool it shouldn't
Symptom: A tool call that should be safe gets blocked with a "DANGEROUS" classification.
Cause: The LLM classifier (Step 3) made an overly cautious decision.
Fix:
- Approve the action manually when prompted — the classifier is advisory, not final.
- If a specific command is consistently blocked, add a targeted permission rule:
cf permission
# → Browse to the relevant category and enable the rule
- You can also inspect why a tool call was classified the way it was:
cf permission --explain '{"tool_name": "Bash", "tool_input": {"command": "your-command-here"}}'
See Auto-Approve reference for the full classification flow.
Auto-approve approves something dangerous
Symptom: A risky operation was auto-approved when it shouldn't have been.
Fix:
- Use
gitto revert any unwanted changes. - Review your permission rules — you may have overly broad allow patterns:
cf permission # Review and tighten rules
- Check if you have dangerous rules like
Bash(*)in your Claude Code settings. The CLI audits these when you enable auto-approve, but they can be added manually later.
Always use auto-approve in projects with version control so you can revert unexpected changes.
Memory System
cf memory start-daemon fails
Symptom: The memory daemon won't start or crashes immediately.
Possible causes:
- Port conflict: Another process is using the same port.
# Check if something is already running
cf memory status
- MCP server not built: The daemon requires the MCP server to be compiled.
# If using from source, rebuild
cd <coding-friend-mcp-dir> && npm run build
- Stale PID file: A previous daemon didn't shut down cleanly.
cf memory stop-daemon # Clean up stale state
cf memory start-daemon # Try again
MCP server not connecting
Symptom: Memory tools (memory_store, memory_search, etc.) are unavailable in Claude Code.
Fix:
- Verify the MCP server is configured:
cf mcp # Shows current MCP configuration and detects stale paths
- Check that
.mcp.jsonuses the version-stable format. Runcf mcp— if it warns about a stale path, update it:
cf memory mcp # Rewrites .mcp.json with the npx format
- Restart Claude Code — MCP servers are connected at session start.
Memory MCP path broken after CLI update
Symptom: Memory tools stop working after running cf update or switching Node.js versions. Claude Code shows an MCP connection error.
Cause: The .mcp.json in your project was written with an absolute path to the old CLI installation (e.g. /Users/you/.nvm/versions/node/v22.x.x/lib/node_modules/coding-friend-cli/...). After the CLI moves, that path no longer exists.
Fix:
cf memory mcp
This rewrites the coding-friend-memory entry in .mcp.json using the version-stable npx format, which resolves the current CLI at runtime and won't break on future updates.
You can also run cf mcp to check whether stale paths are detected before they cause issues.
Memory search returns no results
Symptom: memory_search returns empty even though you have memory files.
Fix:
- Check that memory files exist:
ls docs/memory/
- Rebuild the search index:
cf memory rebuild
- If using Tier 2 (daemon), make sure the daemon is running:
cf memory status
cf memory start-daemon
Skills
Skill not auto-invoking
Symptom: You expect a skill to auto-invoke (e.g., cf-tdd before writing code) but it doesn't.
Cause: Auto-invoked skills depend on the SessionStart and PreToolUse hooks being active.
Fix:
- Make sure Coding Friend is installed:
cf install --user
-
Check that the hook is registered in settings — look for
coding-friendentries in your Claude Code hooks config. -
Start a new Claude Code session — hooks are loaded at session start.
/cf-* command not recognized
Symptom: Typing /cf-plan or another slash command does nothing or shows "unknown command".
Cause: Skills are loaded via the plugin system, not as CLI commands. They only work inside a Claude Code session with Coding Friend installed.
Fix: Make sure you're running the command inside Claude Code (not a regular terminal) and that Coding Friend is installed for the current project or globally.
CLI
cf command not found
Symptom: cf: command not found after installation.
Fix:
# Verify installation
npm list -g coding-friend-cli
# If not installed
npm install -g coding-friend-cli
# If installed but not in PATH, check npm global bin
npm bin -g
Add the npm global bin directory to your PATH if it's not already there.
Still stuck?
If your issue isn't listed here:
- Run
cf statusto see a full diagnostic of your installation - Check GitHub Issues for known problems
- Open a new issue with your
cf statusoutput and steps to reproduce