Audrey

Memory that shows up before your coding agent makes the same mistake twice.

Audrey gives Codex and Claude Code one local, evidence-backed memory loop: remember what mattered, recall it automatically, check before acting, and learn from what happened next.

Memory before action

You fix the deploy command on Monday. On Thursday, a fresh session tries the broken version again.

Audrey brings relevant project memory into the next session, checks supported tool calls before they run, and links their reported outcomes to the check that preceded them. A Guard decision carries evidence IDs you can inspect. Grounding can flag memories that reference deleted files or package scripts.

Try the SQLite-backed demo before configuring a host:

npm exec --yes --package=audrey -- audrey demo --scenario repeated-failure

The demo simulates a failed deploy, passes read-only inspection commands through the hook, and checks a proposed retry. It does not execute a deployment or change host configuration. After npm fetches the package, the demo needs no API key, model download, or network call.

Meet Audrey Autopilot

Install Audrey once, review the hooks once, and then use Codex or Claude Code normally.

npm install -g audrey

audrey install --host auto

Requires Node.js 22.16+ (22.x) or 24+. SQLite is built into Node, so fresh installs and npx launches work without approving dependency scripts. npm 11.17+ may warn about dependency scripts, and npm 12 may report that it blocked them; those scripts are not required for Audrey's CPU embedding runtime.

auto configures whichever supported CLIs are installed. You can choose one explicitly:

audrey install --host codex

audrey install --host claude-code

Restart the host after installation. Codex asks you to trust non-managed hooks once through /hooks; Claude Code may also ask you to approve project or plugin components. Audrey is automatic after that explicit install-and-trust step—never secretly installed.

Autopilot then closes the loop:

An outcome reflects the tool's reported status. A zero exit code can still produce stale or incorrect output. Custom integrations can declare required result checks in beforeAction and supply the actual output to afterAction. Guard then records a mismatch as failed and an unverifiable reported success as unknown. Audrey does not generate application-specific checks or infer the expected values.

Each hook event carries a host-declared timeout (30 seconds for the PreToolUse Guard check). Audrey caps individual hosted embedding/LLM requests below that deadline; this is not a deadline for the entire hook, and local model initialization has no equivalent internal timeout. Errors caught by Audrey fail open by default: the hook emits no decision. Set AUDREY_HOOK_FAIL_CLOSED=1 to deny a PreToolUse action on a caught error. If the host terminates the process first, the host determines what happens. Other lifecycle hooks have no deny path and always degrade open on caught errors.

A small story about a failed deploy

The first attempt fails:

$ npm run deploy

Error: deployment target is missing

Audrey keeps a redacted trace and an action fingerprint. If another session under the same agent identity proposes that action, Guard can deny the retry with evidence. A later recorded success for that fingerprint clears the exact-failure block. If the failed action declared result checks, recovery must pass the same checks. The default exact-failure window is seven days; other memory warnings are evaluated separately.

Fixing a file or deployment target does not itself clear the block. For a deliberate retry, the Guard API accepts acknowledgePriorFailure: true (MCP/REST: acknowledge_prior_failure; CLI: --acknowledge-prior-failure). Autopilot also recognizes retry language in the current user prompt. Acknowledgement lowers the exact-failure block to a warning and preserves its evidence; it does not bypass separate policy warnings.

Guard does not yet evaluate whether a natural-language prerequisite has been satisfied. A trusted must-follow memory can keep blocking even after its suggested repair succeeds. Review the cited rule when that happens; changing a command's spelling is not proof that its underlying problem is fixed.

Looking is not doing

Inspection commands such as grep, git status, and cat normally need no memory check. A non-zero exit from grep can simply mean there was no match.

A command whose every part is positively recognised as read-only skips Guard. The classifier rejects command substitution, redirects other than /dev/null, sudo, xargs, and environment assignments that could change command resolution. Inspection outcomes can be recorded, but are excluded from failure learning. Unrecognised commands remain guarded.

$ grep -rn "prisma" src/          Guard: silent

$ git status --short Guard: silent $ cat prisma/schema.prisma Guard: silent $ npm run deploy Audrey Guard: BLOCKED

• recent_failure (high): This exact Bash action failed before: Prisma client was not generated. Run npm run db:generate before deploy.
• must_follow (high): Before running npm run deploy, run npm run db:generate because Prisma client must be generated first.

This excerpt illustrates the output of audrey demo --scenario repeated-failure.

When Guard does speak, it names the memory it is speaking from, and a remembered failure is matched to the proposed command by what it runs (npm run deploy against npm run deploy), not by how similar two strings look to an embedding.

Commands with execution-capable options or lifecycle scripts are guarded, including git ls-remote --upload-pack=..., npm pack --dry-run, and ss -K. The classifier is a convenience for ordinary inspection commands, not an operating-system sandbox. Repository configuration, shell expansion, and programs invoked by a reader can change what a command does. Use host permissions or a sandbox when enforcement is required.

What Audrey remembers

Audrey treats memory as more than a pile of text chunks.

• Episodes are things that happened: a user decision, a tool result, a project fact, a preference.
• Semantic memories are principles supported by accumulated evidence.
• Procedural memories are ways of acting: how to retry, verify, avoid, or recover.
• Contradictions stay visible instead of being silently overwritten.
• Confidence changes with source quality, evidence, age, retrieval, interference, context, and feedback.
• Low-value memories decay; repeated evidence can consolidate into longer-lived knowledge.

Every context packet includes memory IDs, confidence, provenance where available, and a reason for inclusion. Uncertain or disputed memories are labeled as such. Retrieved content is wrapped with a simple rule: memory is evidence, not authority; current system and user instructions always win.

Checking memories against the repository

Age is not the only way a memory goes wrong. A note saying "ship with npm run deploy:prod" is perfectly recent, well sourced, and completely wrong the day that script is deleted. Worse, every recall reinforces it, because retrieval counts as evidence that a memory is useful. A confidently stated, well-supported, false instruction is more damaging than no memory at all.

Audrey checks a narrow, useful part of this problem: whether referenced repository paths and package script names still exist. When a memory is written with project context, it records only anchors that resolve at that moment. A missing anchor can then distinguish a later repository change from a reference that never resolved.

Existence does not establish correctness. A script can keep its name while changing behavior, and an intact file can contain obsolete instructions. Grounding does not execute scripts, prove a fix, or verify arbitrary claims in prose.

audrey ground

[audrey] Grounding memories against /home/you/project

[audrey] Checked 14: 12 still true, 2 broken, 0 repaired. [audrey] 01K8ZQ... references a missing npm_script: deploy:prod [audrey] 01K8ZR... references a missing path: scripts/release.mjs

Broken memories are not deleted. They keep their content, say plainly what they still refer to, and take a confidence penalty so they stop leading by default while remaining readable and repairable. They also stop being eligible for the packet's must-follow section — that is the section that can force a Guard block, and a rule naming a file that no longer exists is a rule nobody can follow.

Repair is symmetric. Restore the file or the script and the next check clears the flag. A checkout that has moved reports unknown rather than broken, because a memory should not be discredited for describing a project this machine cannot currently see.

Memories with no checkable claims are left unlabeled. Silence is not a clean bill of health, and presenting it as one would be the same mistake pointed the other way.

Daily use

Most of this runs on its own once Autopilot is installed. You do not invoke recall, and you do not invoke Guard. The table is here for the parts you would reach for deliberately, and so the automatic parts are legible rather than magic.

| Consolidation | Automatic when idle; manually before a long break | Repeated ep