Agent Memory Hook Package Installation
This rule watches for command lines that install packages or write config files aimed at giving Claude Code, Codex, or Grok persistent memory or hook-based behavior. It flags the installation step itself, not proof that memory was actually written or agent behavior was actually changed.
How the attack works
An agent, or a process it spawned, runs a command that either installs an npm-ecosystem package whose name references one of these coding-assistant platforms together with a memory/context-compression feature, or writes to a known agent config/hook location (like ~/.claude/settings.json, ~/.claude/hooks, ~/.codex/config.toml, ~/.config/grok) while the same command line contains a memory/compaction/persistence keyword. This pattern matters because agent hooks and memory plugins can be used to make an agent retain attacker-influenced context or run attacker-supplied code on every future session. The rule requires three independent matching tokens in one command line, so ordinary package installs or generic script execution won't trigger it.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- 7b3f1c2e-9d84-4a5f-b6c1-2e8a4f0d51c7
- Severity
- Medium
Why it matters
If real, this step can let an attacker embed a persistent hook or memory module into a developer's AI coding assistant, giving them a foothold that survives across sessions and could influence or exfiltrate future agent activity. The rule only confirms the installation command was run — it does not confirm the hook was actually registered or that agent memory was actually altered.
What you can do
- →Review any flagged installation commands manually to confirm whether the package or config change was intentional and authored by a known developer.
- →Maintain an allowlist of approved memory/hook packages and config changes for your agent tooling, and treat unlisted ones as suspicious.
- →Restrict write access to agent config directories (~/.claude, ~/.codex, ~/.config/grok) to trusted provisioning processes only.
- →Audit installed hook/memory packages periodically to catch ones that slipped in outside of your normal onboarding or CI process.
Known benign look-alikes
- Developer intentionally installing a memory or context MCP server / hook package for their own agent setup (e.g. an internally authored session-memory hook).
- Dotfile or machine-provisioning scripts that copy a hooks file or settings.json into ~/.claude, ~/.codex or ~/.config/grok during onboarding.
- CI images that install agent tooling whose package name legitimately contains "context" or "memory" (context7-style docs servers, memory-bank plugins).
- Backup or migration one-liners that cp/mv an existing agent settings.json while a memory-related package name happens to be on the same command line.
- Security research replaying the described npm package inside a sandbox.