Skip to content
postmq
Support Sign in Get started
Compare

PostMQ and Claude Code auto memory do different jobs.

Auto memory is your client's own memory, kept for your client's own context — machine-local by design, on by default, and yours to edit. PostMQ is a shared record of the work: decisions, deferrals, rules asked for, what a session cost, attributed and append-only, outliving one client and one machine. This page compares them row by row, with a source on both sides of every row, and recommends running both.

Read the comparison When auto memory is enough

How this page is sourced

both columns, or the row is cut

Their column: one page Anthropic publishes, quoted, with the section footnoted.

Read on: 2026-08-18. Their documentation can change; this date says when we looked.

Our column: the claims register, which is pinned to files and tests in the repository.

Cut rows: anything we could not cite to their own page — listed below, not hidden.

no screenshots · no logos · no inferred internals

complementary, not competitive verified 2026-08-19
What each is for

Two records, and they are not the same record

One paragraph each. The paragraph about Claude Code is entirely quotation and paraphrase from Anthropic's own documentation, read on the date at the foot of this page.

Claude Code's memory. Anthropic's own documentation describes two mechanisms that carry knowledge between sessions, because "each Claude Code session begins with a fresh context window": CLAUDE.md files, which are "instructions you write to give Claude persistent context", and auto memory, which is "notes Claude writes itself based on your corrections and preferences". Auto memory is on by default; it keeps what the docs list as "build commands, debugging insights, architecture notes, code style preferences, and workflow habits" in a directory the docs give as ~/.claude/projects/<project>/memory/, one per git repository and shared across that repository's worktrees. The page states the boundary itself: "Auto memory is machine-local … Files are not shared across machines or cloud environments." The hand-written half travels differently — the same page's table lists a project CLAUDE.md as shared with "Team members via source control". Both are loaded at the start of every conversation, and both, in the page's words, are treated as "context, not enforced configuration".

PostMQ. PostMQ is a hosted session-state platform an agent writes into over MCP or the versioned /v1 REST API while it works: it opens a build session against a project, computer, branch and actor; asks which rules apply to the change it is about to make; files decisions into an append-only log; files what it deferred into a triaged backlog; and reports what the session consumed. The workspace is resolved from the credential presented on each call rather than passed in, every entry is attributed to that credential, and each write lands a row on the workspace's tamper-evident audit chain in the same transaction as the write itself. It speaks standard MCP, so any MCP client can be the one writing.

Those two descriptions do not overlap as much as the word "memory" suggests. One is the working context of a client on a machine; the other is the record of what was decided, by which identity, in which session. A team can want both and, in this repository, does: the sections below compare them on ten axes, say plainly where the client's own memory alone is the right answer, and end on the arrangement we actually run.

One place the two do genuinely meet is worth naming before the table rather than after it, because a comparison page is tempted to leave it out: narrowing guidance to the work in hand. Claude Code already does this — the same documentation describes path-scoped rules in .claude/rules/, whose paths: frontmatter means those rules "only apply when Claude is working with files matching the specified patterns". PostMQ's answer is a query the agent makes rather than a file the client loads, and the row below says which is which; neither is the absence of the other.

The comparison

Ten rows, and a source on both sides of each

Rows 8 and 9 are here because the answers agree, not because they differ — a matrix that showed only the differences would be selling rather than comparing.

what is being compared PostMQour claims register Claude Code memoryAnthropic's documentation
Who writes it The agent, through an MCP tool or a REST call. The entry is stamped server-side with the credential that made the call and linked to that credential’s open build session, so the name on the record is not one the caller supplied. P1 Anthropic’s comparison table carries a “Who writes it” row with one answer for each mechanism: “You” for CLAUDE.md files, “Claude” for auto memory — which the page describes as “notes Claude writes itself based on your corrections and preferences”. A1
Where it lives A hosted workspace. The rows are read back over the versioned /v1 REST API, the MCP query tools and the dashboard, all on one service layer, and the workspace itself is resolved from the presented credential rather than passed in. P2 Files on the machine you are working on. “Each project gets its own memory directory at ~/.claude/projects/<project>/memory/”, holding a MEMORY.md index and optional topic files. A2
How far auto memory reaches One workspace, reachable from any MCP client on any machine. A session records the project, the computer, the branch and the acting agent, and link_build_session_continuation records a resume that crossed to another machine or another branch. P3 Stated in the documentation itself: “Auto memory is machine-local. All worktrees and subdirectories within the same git repository share one auto memory directory. Files are not shared across machines or cloud environments.” A2
How far a written CLAUDE.md reaches The same one record — there is no second, file-based copy to keep in step. Every reader, whether a person in the dashboard, an agent over MCP or a script on the versioned /v1 routes, is reading the workspace itself through one service layer. P2 As far as your version control does, which is a real answer and belongs on this page: the scope table lists a project CLAUDE.md as shared with “Team members via source control”, a user CLAUDE.md with “Just you (all projects)”, and a managed-policy one with “All users in organization”. A3
How an entry changes It does not. A database trigger refuses every delete and every update except the two source links, so a change of judgement is filed as a correction that points at the entry it supersedes and both stay readable. P4 “Auto memory files are plain markdown you can edit or delete at any time.” The docs also describe Claude Code prompting Claude to keep the index short — “keep one line per entry, move detail into topic files, and merge or drop stale entries”. A6
What reaches the model when a session starts Nothing on its own. The agent calls start_build_session, reads the previous session’s current-state lead, and asks for whatever else it needs — the applicable rules, the open backlog, the last decisions. P5 “The first 200 lines of MEMORY.md, or the first 25KB, whichever comes first, are loaded at the start of every conversation. Content beyond that threshold is not loaded at session start.” Topic files “are not loaded at startup. Claude reads them on demand using its standard file tools when it needs the information.” CLAUDE.md files load in full. A4
How guidance is narrowed to the work at hand query_applicable_rules takes the file paths, the operation, the languages, the project attributes and the task context the agent is about to touch, and returns only rules whose every populated dimension matches — with the candidate and suppressed counts, and a retrieval count bumped on each rule it returns. P6 Path-scoped rules. A markdown file under .claude/rules/ with a paths: frontmatter holds rules that “only apply when Claude is working with files matching the specified patterns”, and they “trigger when Claude reads files matching the pattern, not on every tool use”; a rule with no paths field loads unconditionally. A5
Whether it can stop an action No. Nothing in PostMQ intercepts, evaluates or refuses an agent’s tool call; a rule it returns is advisory, and enforcement stays in your CI. It is governance by record, not by gate. P7 No, and the page says so plainly: “Claude treats them as context, not enforced configuration. To block an action regardless of what Claude decides, use a PreToolUse hook instead.” A1
What it costs to switch on A workspace, an AI account and a scoped, once-disclosed credential; then one .mcp.json entry and one client restart so the tool catalog is refetched. P8 Nothing: “Auto memory is on by default.” A CLAUDE.md is a markdown file you write, and /init will draft a first one from the codebase. A2
How long it is kept Audit rows have no deletion path anywhere in the code and are kept as long as the workspace exists; message payloads are anonymised 30 days past acceptance. Every ledger is readable over the versioned /v1 routes — and there is no one-click export. P9 “Claude Code deletes old session transcripts after the cleanupPeriodDays retention period, but excludes the files in the memory directory from that retention sweep. MEMORY.md and topic files stay until you or Claude edits or deletes them.” A2
  1. A1. Anthropic, “How Claude remembers your project” (Claude Code documentation) — “CLAUDE.md vs auto memory”: the two mechanisms, who writes each, and “Claude treats them as context, not enforced configuration” — https://code.claude.com/docs/en/memory#claude-md-files , retrieved 2026-08-18
  2. A2. Anthropic, “How Claude remembers your project” (Claude Code documentation) — “Auto memory”, “Storage location” and “Enable or disable auto memory”: the per-repository directory, “Auto memory is machine-local … Files are not shared across machines or cloud environments”, “Auto memory is on by default”, and the retention paragraph — https://code.claude.com/docs/en/memory#auto-memory , retrieved 2026-08-18
  3. A3. Anthropic, “How Claude remembers your project” (Claude Code documentation) — “Choose where to put CLAUDE.md files”: the four scopes and the “Shared with” column (“Team members via source control”) — https://code.claude.com/docs/en/memory#choose-where-to-put-claude-md-files , retrieved 2026-08-18
  4. A4. Anthropic, “How Claude remembers your project” (Claude Code documentation) — “How it works” and “Write effective instructions”: the 200-line / 25KB index load, topic files read on demand, and CLAUDE.md loaded in full at the start of every session — https://code.claude.com/docs/en/memory#write-effective-instructions , retrieved 2026-08-18
  5. A5. Anthropic, “How Claude remembers your project” (Claude Code documentation) — “Path-specific rules”: rules with a paths: frontmatter “only apply when Claude is working with files matching the specified patterns” — https://code.claude.com/docs/en/memory#path-specific-rules , retrieved 2026-08-18
  6. A6. Anthropic, “How Claude remembers your project” (Claude Code documentation) — “Audit and edit your memory”: “Auto memory files are plain markdown you can edit or delete at any time.” — https://code.claude.com/docs/en/memory#auto-memory , retrieved 2026-08-18
  7. P1. claims register C59, C58 — every entry is attributed to the credential that wrote it and auto-linked to the caller’s open build session
  8. P2. claims register C04, C124 — a hosted workspace behind the versioned /v1 REST API, the MCP tools and the dashboard; the workspace is resolved from the presented credential
  9. P3. claims register C03, C06, C84 — standard MCP from any client; a session keyed on project, computer, branch and actor, with an explicit continuation link across machines
  10. P4. claims register C07, C08 — a database trigger refuses every delete and every update but the two source links; a correction is a new entry pointing at the one it supersedes
  11. P5. claims register C81, C09 — a session opens on the previous session’s current-state lead and the agent asks for what it needs
  12. P6. claims register C09, C68, C69, C10 — query_applicable_rules matches five trigger dimensions, AND across the populated ones, and bumps each returned rule’s retrieval count
  13. P7. claims register C119 — governance by record, not by gate: nothing intercepts, evaluates or refuses an agent’s tool call
  14. P8. claims register C36, C80 — an AI account and a scoped, once-disclosed credential, one .mcp.json entry and one client restart
  15. P9. claims register C123 — every ledger readable over the versioned /v1 routes; no one-click export; payloads anonymised at 30 days; no deletion path for audit rows

Every "Claude Code memory" cell above is a quotation or close paraphrase from one page Anthropic publishes, footnoted to the section it came from and read on 2026-08-18. That date is deliberately separate from the last-verified date at the foot of this page: our half is pinned to files and tests in a repository that cannot change under us, and their half is somebody else's page that can. If you find a row that no longer matches what their documentation says, it is wrong and we want to know.

What was cut, and why it matters more than what was kept. Six rows were drafted and removed: the integrity of their files, per-writer attribution, a search surface over the record, price, whether team-shared memory exists behind a flag, and the reading of the 200-line index as a ceiling. Each one would have needed a right-hand cell asserting that something is absent from their product — and an absence is the one claim a citation to somebody else's documentation cannot carry, because a page that does not discuss a thing is not a page that denies it. Where our side of such a point is worth stating, it is in the next section but one, cited only to our own register and making no claim about theirs.

When to use auto memory alone

Five reasons to stop reading here

The mandatory honest section, and it is meant honestly: for a large number of people, the client's own memory is the whole answer and PostMQ would be overhead.

  1. There is nothing to set up. "Auto memory is on by default," and a CLAUDE.md is a markdown file in your repository that /init will draft for you from the codebase. There is no account to create, no configuration entry to add and no client to restart. PostMQ asks for a workspace, one configuration entry, one approval and a restart before it does anything at all — and where the client does not implement MCP authorization, or there is no browser to approve in, a credential you issue and supply as well.
  2. There is no server, so there is nothing to operate. The files are on the disk in front of you, in a directory the documentation names. Nothing has to be reachable for your agent to read them, no request leaves the machine to fetch them, and nobody has to run anything for them to keep working next week.
  3. It is already in the client you have. The docs describe /memory listing the memory file locations and opening any of them in your editor, and /context showing which files actually loaded into the current session. That is a shorter path to "what does it think it knows" than any hosted product can offer.
  4. You do not have to remember to use it. Auto memory writes itself: the docs say Claude "saves notes for itself as it works" and "decides what's worth remembering based on whether the information would be useful in a future conversation". PostMQ records what an agent deliberately tells it — the server does not enforce the protocol, so a session that never calls the tools leaves no record at all. That is a real cost, and it is ours.
  5. The files are yours, in a format you already read. "Auto memory files are plain markdown you can edit or delete at any time." No export step, no API, no schema to learn, and the retention paragraph says memory files are excluded from the transcript cleanup sweep and "stay until you or Claude edits or deletes them".
What a shared record adds

Five properties, each cited to our own register

Nothing in this section is a claim about anybody else's product. It is what a hosted, attributed, append-only record does that a record kept as files on one machine is not trying to do.

It survives a change of machine and a change of person

The workspace is resolved from the presented credential on every call, and a session carries the project, the computer, the branch and the acting agent it ran under.

A session that stops on one machine and resumes on another is recorded as a continuation of the first rather than as an unrelated second session, so the trail through a piece of work is one trail. Nothing about that depends on which client was used: it speaks standard MCP, so any MCP client can write into the same record.

tool:link_build_session_continuation

Every entry names who wrote it, and it is not a name they chose

The actor key is derived server-side from the credential the call authenticated with, and the entry is auto-linked to that credential’s open build session.

This is the property that makes a record usable in a review months later. You are not reading "somebody decided" — you are reading which agent identity decided, in which session, on which branch, over which transport. A client cannot assert an identity it was not issued.

field:actor_key

A change of mind is added, not applied over the top

A database trigger refuses every delete and every update except the two source links; correcting an entry files a new one that points at the entry it supersedes.

The value is not that a later view is right — it is that the earlier view is still there with its date, so the reasoning that produced a decision is legible even after the decision is reversed. A ledger that can be tidied is a ledger you have to trust somebody not to tidy.

trigger:append-only

An agent can ask it a question at the moment it matters

query_applicable_rules matches five trigger dimensions — file globs, operations, languages, project attributes and code patterns — AND across the populated ones, and records the retrieval on each rule it returns.

Retrieval is a call the agent makes with the change it is about to attempt, and the answer is a set of rules with counts attached: how many were candidates, how many were suppressed. Because each returned rule’s retrieval count moves, you can see afterwards which guidance was actually consulted, rather than which guidance existed.

tool:query_applicable_rules

The whole thing sits on a tamper-evident chain

Each row’s hash is computed inside the same SQL transaction that inserts it, over the canonical row, its sequence number and the previous row’s hash; the application’s database identity is denied UPDATE and DELETE on that table.

Read the boundary with the claim, because it is narrower than a trust page usually admits: your own three read surfaces deliberately return the rows and the integrity sweep’s verdict rather than the hashes, and re-deriving a link yourself needs the transparency artefact, whose per-workspace publication is opt-in, toggled from the dashboard. Tamper-evident means a break is detected, not that a row cannot be rewritten.

table:audit_log

Read those five as one property rather than five: a record several parties write into needs attribution you cannot forge, an edit history you cannot flatten, and a way to be asked a question at the moment a decision is being made. Each falls over without the others. None of them is enforcement: a rule that comes back from a query is advisory, PostMQ does not block a tool call, and what changes is what is on the record afterwards. And read the last one with its limits — the workspace-facing audit surfaces deliberately return the rows and the verifier's verdict rather than the hashes, re-derivation needs an artefact whose publication is opt-in, and no verifier ships, so a reviewer writes that script themselves. Details on the decision log, on rules, and on session state.

Use both

The arrangement this repository actually runs

Not a diplomatic ending. It is the setup behind the numbers on this site, and the division of labour is worth stating concretely.

Auto memory stays on and keeps what Anthropic's documentation says it keeps — "build commands, debugging insights, architecture notes, code style preferences, and workflow habits" — which here means the build incantation for this repository, the shape of a test fixture, the fact that a particular suite has to run alone. Those are working notes for a client on a machine, they change often, and nobody needs a hash chain over them. PostMQ holds the other thing: the decision that a sweep ships disabled and why, the backlog item that decision deferred, the lesson a failure produced and the rule that lesson became.

A concrete example, from this week. A session working on a lock ordering found that a race test was passing against unfixed code. Two facts came out of that afternoon, and they belong in different places. "Run this suite with the whole assembly, not the class alone" is a working note about this machine and this repository — auto memory's job, and it will be right there in the next session on this checkout. "Pin one side of a race mid-transaction; a wait assertion proves blocking and never ordering" is a decision with a rationale, filed into the log with the session, the branch and the agent that filed it, and later derived into a rule that comes back from query_applicable_rules the next time any agent, on any machine, touches a file matching the lock-test glob. One of those two needs to travel; the other does not.

Wiring it is one entry and one restart: the Claude Code page carries the .mcp.json snippet, the credential step and the two skills and two hooks we run around a session — and states plainly that the server does not enforce any of it, which is why the protocol is written down rather than assumed. Start from the overview if you want the shape of the loop first.

Questions

Six questions this comparison raises

No, and we would not suggest it. They hold different things. Anthropic’s own documentation describes auto memory as the notes Claude writes itself — “build commands, debugging insights, architecture notes, code style preferences, and workflow habits” — living in a per-repository directory on the machine you are working on, and on by default. That is the client’s own working context and it is genuinely useful for exactly that. What PostMQ holds is the record of the work: the decisions with their rationale, the deferrals, the rules the agent asked for, what a session cost. The two do not compete for the same slot, and the setup we run ourselves has both switched on.

Auto memory is documented as machine-local and editable — one directory per git repository, “not shared across machines or cloud environments”, and “plain markdown you can edit or delete at any time”. PostMQ is a hosted ledger that several machines and several agents write into, where an entry is attributed to the credential that wrote it and a change of judgement is filed as a correction rather than an edit. If your record needs to be one record across people and machines, that is the difference; if it does not, it is overhead.

It does, and any comparison that pretends otherwise is wrong. Anthropic’s documentation describes a .claude/rules/ directory whose files can carry a paths: frontmatter, and those “only apply when Claude is working with files matching the specified patterns”. The difference is mechanism, not presence: theirs is glob-matched markdown the client loads when it reads a matching file; ours is a call the agent makes — with the paths, the operation, the languages, the project attributes and the task context — that comes back with the matching rules and the counts of what was considered and what was suppressed. Both are reasonable answers to the same problem.

No. Nothing in PostMQ intercepts, evaluates or refuses an agent’s tool call, nothing inspects payload content for style, and a rule that comes back from a query is advisory. It is worth noticing that both products say the same thing here: Anthropic’s page states that CLAUDE.md and auto memory are treated as “context, not enforced configuration”, and points at a PreToolUse hook for anything that must hold regardless. Enforcement belongs in your CI and in your client’s hooks; what PostMQ adds is the record of what was asked for and what was decided.

Each one from a section of a single page Anthropic publishes — “How Claude remembers your project” at https://code.claude.com/docs/en/memory — read on 2026-08-18, with the footnote under the table pointing at the section the quotation came from. Nothing in that column is inferred from behaviour, measured by us, or taken from a third-party write-up; if we could not cite it to their page on that day, the row was cut rather than softened. The claims register rows C132 to C136 hold the quotations, so a future edit to this page is checked against what was actually read rather than against memory.

No. PostMQ speaks standard MCP and Claude Code is an MCP client, which is the whole of the relationship: you paste one .mcp.json entry and restart the client. Claude, Claude Code and CLAUDE.md are Anthropic’s; PostMQ is not affiliated with or endorsed by Anthropic, and nothing on this page should be read as their statement about us or ours about their roadmap.

Last verified 2026-08-19 against main at 3694399: the decision-log trigger and its correction path, the five trigger dimensions and the retrieval bump, the session identity tuple and the continuation link, the actor key derived from the credential, the audit chain's insert-transaction hashing and the denied UPDATE/DELETE grant, and the retention and export positions were each read on that day.

The Claude Code facts on this page were read from Anthropic's own documentation on 2026-08-18 — https://code.claude.com/docs/en/memory, "How Claude remembers your project" — and every one of them is footnoted to the section it came from. Claude, Claude Code and CLAUDE.md are Anthropic's; PostMQ is not affiliated with or endorsed by Anthropic, and nothing here is their statement about this product.

Related: session state — the loop this record is written by · the decision log a trigger makes append-only · rules an agent asks for before it acts · the Claude Code setup we run · security — the chain and what it does not show you.

Keep your client's memory. Add a record that outlives it.

One .mcp.json entry and one restart, on the free Developer allowances. Auto memory stays exactly where it is.

Set up Claude Code See what a session records