You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With the help of Claude code, I conducted a full source review of all 114 files in src/ and bin/, running the same review prompt in two environments: a clean Mac terminal (no agentic-kit installed, reading the cloned source only) and a GitHub Codespace after ak setup had run (with injected CLAUDE.md blocks and auto-approved permissions active). The two reviews were compared for variance to check whether the injected guidance influenced the analysis.
Both reviews converged on the same substantive findings. The seven items below are the actionable ones.
Findings
heal.mjs reports success on two distinct failure paths The ruvnet-brain npx installer marks ✓ on exit code 1 if KB files are present on disk — observed firsthand during a Codespace ak setup run (✓ ruvnet-brain: exit 1). The presence check doesn't confirm the install completed correctly; it could be partial or stale. Separately, healAqeSolver() returns ok:true when the native solver install fails because a TS fallback exists, masking a real install failure. Suggestion: return a distinct status (e.g. ok:true, degraded:true, detail:"...") so ak status can distinguish "installed" from "fell back to a slower alternative."
sqlite.mjs withDb() cannot distinguish empty from corrupt The catch { return fallback } pattern swallows all errors — missing file, locked DB, corrupt schema, bad SQL — with zero logging and no differentiation. A corrupt memory.db looks identical to "no entries yet." A locked DB during concurrent access looks identical to "no data." A genuine SQL bug in calling code is silently hidden. Suggestion: at minimum log at debug level; ideally distinguish expected-absent (ENOENT → fallback) from unexpected-failure (corrupt/locked/SQL error → warning or distinct return value).
settings.mjs silently swallows backup failure before overwriting writeJsonWithBackup() copies the existing file to .bak before overwriting. If the backup fails (permissions, disk full), the error is silently caught and the overwrite proceeds with no signal to the caller. The backup-first safety guarantee documented throughout the codebase isn't actually guaranteed. Suggestion: warn on backup failure, or fail the write if the backup can't be created.
blocks.mjs has the same silent backup-failure pattern The backup step before rewriting ~/.claude/CLAUDE.md and AGENTS.md files uses try{fs.copyFileSync(file,bak)}catch{/* best-effort */}. Same risk as install.sh fills Claude Code sandbox tmpfs, causing session crashes (ENOSPC) #3 but higher stakes — CLAUDE.md content directly shapes Claude Code's behavior. A failed backup combined with a bad write could leave corrupted guidance with no recovery file.
statusline-footer.cjs has ~15 empty catch(e){} blocks with zero logging The design rationale is documented and sound ("a broken tee must never cost a statusline render"), and the fail-to-blank (not fail-to-fabricate) polarity is the right choice — the explicit avoidance of the prior fabricated-CVE-counter bug class is thoughtful. However, any bug in this file is permanently invisible: no log, no diagnostic, no signal that a segment failed. Suggestion: add an optional debug log gated on an env var (e.g. AK_STATUSLINE_DEBUG=1) so failures can be surfaced during development without affecting production behavior.
process-sessions.mjs surveys the entire OS process table without scoping ps -axo pid=,ppid=,lstart=,comm=,args= reads process metadata for all processes on the host, not scoped to the current user or project. On a shared machine this could expose the existence and working directories of other users' Claude/Codex sessions. The data is used read-only for the dashboard, and project-label.mjs hashes paths before display, but raw cwds are resolved and held in memory before hashing. Suggestion: document this as an explicit privacy consideration and consider scoping to the current user's processes.
ak setup does not surface the 7 auto-approve permissions it writes Setup writes 7 tool auto-approve permissions into .claude/settings.json (mcp__claude-flow__, mcp__agentic-qe__, Bash(npx @claude-flow*), Bash(npx claude-flow*), Bash(node .claude/), Bash(npx agentic-qe:), Bash(npx @anthropics/agentic-qe:*)). Claude Code surfaces these on first launch with a trust prompt, but ak setup itself does not list what it's auto-approving during the setup flow. A user may not realize these were planted until Claude Code asks about them in a different context. Suggestion: print the permission list during setup so users can make an informed trust decision at the point of installation.
With the help of Claude code, I conducted a full source review of all 114 files in src/ and bin/, running the same review prompt in two environments: a clean Mac terminal (no agentic-kit installed, reading the cloned source only) and a GitHub Codespace after ak setup had run (with injected CLAUDE.md blocks and auto-approved permissions active). The two reviews were compared for variance to check whether the injected guidance influenced the analysis.
Both reviews converged on the same substantive findings. The seven items below are the actionable ones.
Findings