Security considerations when using caveman in sensitive dev environments

[fmendezy]

Security Review: Using caveman in environments with sensitive code

Hi — I ran a detailed security audit of caveman before deciding whether to install it in our development environment (a SaaS B2B multi-tenant app). Sharing the findings here in case they are useful to the community and the maintainer.

TL;DR: caveman introduces real security risks for developers working with sensitive codebases. Four areas worth addressing.

---

1. caveman-compress exfiltrates files to Anthropic API

The compress script reads up to 500KB of any file and sends it to the Anthropic API. If a developer accidentally — or via a manipulated prompt — runs it against a .env file, prisma.schema, or any file containing credentials or PII, that content leaves the local machine and goes to a third-party API outside the organization's control.

The subprocess fallback (subprocess.run(['claude', '--print'], ...)) makes this worse: the script can invoke Claude Code itself as a subprocess with arbitrary content.

Suggestion: Add explicit file allowlist/denylist validation (e.g., reject .env, *.pem, *secret*, *credential*). Also consider showing the user exactly what will be sent before sending.

---

2. UserPromptSubmit hook reads every prompt

The hook has full technical access to read, modify, and block every prompt before it reaches the model. Today the intent is clearly benign — but this is a high-trust surface.

For developers working on auth systems, multi-tenant data isolation, or security-sensitive code, having a third-party hook intercept every prompt is a significant trust requirement. A future supply chain compromise (even a subtle one-line change) could silently log or modify prompts containing schema names, SQL queries, or security logic.

Suggestion: Document explicitly in the README what the hook does and does not do with prompt content, and consider scoping it to only match on known /caveman commands rather than processing every prompt.

---

3. Symlink file-clobber (Issues #70 and #71 — open, no fix yet)

Both hooks call fs.writeFileSync(flagPath, ...) without checking whether flagPath is a symlink first. These hooks run automatically on every session start and every prompt, which means the attack surface is constant.

On Linux/macOS, a malicious or compromised process that plants a symlink at ~/.claude/.caveman-active pointing to ~/.ssh/authorized_keys, ~/.bashrc, or ~/.claude/settings.json would get those files overwritten silently.

Suggestion: Fix with lstat() + symlink check before writing, as proposed in the open PRs. This is a straightforward fix — would be good to get it merged.

---

4. SessionStart hook injects instructions outside version control

The instructions injected at session start live in ~/.claude/hooks/caveman-activate.js, not in the project repository. They apply to every Claude Code session on the machine, including sessions for unrelated projects. Developers who work on security-sensitive tasks (auth, data access, PII handling) and use Claude Code for that work will have caveman's instructions active without necessarily being aware of it.

Suggestion: Consider making the session-level injection opt-in per project (e.g., triggered by presence of a .caveman file in the project root) rather than global by default.

---

Notes

These findings are not a statement that caveman is malicious — the project clearly has good intent and the compression concept is useful. The concerns are about the attack surface it introduces and the trust requirements for developers using it in environments with credentials, PII, or sensitive business logic.

For purely personal projects or hobby coding, most of these are low-concern. For professional environments, the risks above are worth evaluating.

Happy to discuss any of this or provide more detail on specific scenarios.

---

Checked against: caveman main branch, April 2026, Issues #70, #71, #78.

[JuliusBrussee]

Appreciate the investigation, I'll be shipping fixes to all this soon.

[JuliusBrussee]

1.6.0 should fix all of these issues!