Claude Opus 5's System Prompt Leaks: 800 Lines of Memory Filesystem Rules

On July 24, Anthropic released Claude Opus 5.

Then I saw its system prompt used on claude.ai in elder-plinius's CL4R1T4S repository.

CL4R1T4S is a familiar name — this security researcher previously extracted Fable 5's prompt.

A total of 2049 lines. From L164 to L963, a full 800 lines are dedicated to teaching Claude how to remember a person, when to modify files, which file to write to, what information must never be saved, and how to detect and merge conflicts when multiple Claude sessions modify the same memory simultaneously.

In Fable 5's extracted prompt, memory_system had only two items.

• First, Claude has a memory system that can read user information distilled from past conversations;
• Second, the current user has not enabled memory in Settings, so Claude currently has no memory of this user available.

With Opus 5, this thing has directly become a memory filesystem.

Fable 5's Two Lines of Memory Became Opus's 800 Lines

The screenshot above shows the two Fable 5 memory instructions mentioned earlier. It ends there, basically saying nothing of substance.

Below it, Opus 5 replaces it with memory_filesystem, and the opening sentence makes it clear: this is a working memory that persists across sessions.

▲ Top: Fable 5 original L166-L170; Bottom: Opus 5 original L164-L182

The line at the bottom of the screenshot, future-you needs the context, translates to: write information into the file because the next instance of Claude needs this context, not because the user specifically said "please remember this information," so choose to remember. At the start of each new conversation, Claude re-reads these memory files.

Immediately after, the prompt reminds it: you are currently running in a chat interface, and other Claude interfaces may also read or write the same file — another session might have already modified a file before this conversation even ends. So Claude cannot assume that what it just read has remained unchanged.

Below are six specific tools:

• memory_read reads files;
• memory_write creates new files or rewrites entire files;
• memory_str_replace performs partial replacements;
• memory_append appends to the end;
• memory_list re-reads the file list;
• memory_delete deletes entire files.

In Opus 5, memory has been implemented as files, directories, version numbers, and read/write tools. The roughly 800 lines that follow all describe the usage rules for this memory system.

Claude Remembers Automatically, Without You Asking

The second screenshot is titled When to write — when to write to memory.

▲ Opus 5 original L390-L416

The first sentence of the screenshot can be translated literally as: write to files during the conversation, don't wait until the conversation ends, and don't wait for the user to proactively ask.

If the user says once "my favorite X is Y," "I work as Z," or "I work at W," that's enough — no need to wait for a second message to confirm.

If the user says "use X" or "I choose Y," that also counts as a decision already made. Claude will record these decisions first, then handle the subsequent request.

The original text also requires Claude not to record things at the end. If it's about to ask a follow-up, search, or call another tool, it should first save the constraints, intentions, and facts the user has already stated. If the conversation ends right there, this information won't be lost.

The screenshot gives a concrete example:

I'm learning X through Y, any suggestions?

This sentence contains both a fact and a question.

Claude should first record that the user is learning X through Y, then answer with suggestions. If there's only a question, such as "what should I do in Tokyo," or information that will quickly become invalid, such as tonight's hotel room number, these will not be written to memory.

Claude places memories in the following files.

• /profile.md holds identity information that is likely still valid three months later;
• /topics/ holds diet, commute, interests, and habits;
• /areas/ holds ongoing projects, courses, or matters;
• /people/ holds relationship context for family, friends, and colleagues;
• /preferences.md records how the user wants Claude to respond.

▲ Opus 5 original L329-L359

This image also contains two judgment criteria. Information in /profile.md is suitable for saving only if it will still be valid three months later. For example, "started working as a platform engineer in March" can be written in, but "migrating the authentication system this week" should go in /areas/. /topics/ allows saving one-time expressions of interest — if the user only mentioned liking bubble tea once, it can still be written into the diet file first.

▲ Opus 5 original L361-L388

The second image continues explaining the remaining three directories. /areas/ isn't just for formal projects — ongoing matters like on-call duty, house hunting, and tax filing also count. /people/ only saves the relationship context between this person and the user, but must not be written as a personal profile. /preferences.md saves user preferences, such as "keep replies brief" or "I prefer tables" — not what the user likes to eat or do for fun.

When updating existing records, direct replacement is also not allowed. The original text gives an example: if the file originally says "drinks coffee every morning" and the user later switches to only drinking tea, Claude must replace the original sentence with "now drinks tea, used to drink coffee." This way, the file won't simultaneously retain two conflicting habits.

Every time a file is updated, the version number just read must also be included. If another Claude interface has already modified the same file, this write will receive a conflict notification. Claude must merge both sides' changes based on the latest content and cannot overwrite the current version with an old one.

(This is just like write conflicts in concurrency)

So it won't stuff entire chat sessions into memory. It saves facts the user has explicitly stated that will remain valid months later.

For proactive write rules, see original L390-L420; for version conflict handling, see original L561-L632.

The Hard Part Is Knowing What Not to Remember

Before writing, Claude first filters out content that cannot be saved.

The prompt first gives a method for judging whether to write: if the user saw this record on a settings page and would mind a colleague standing next to them seeing it, then don't save it.

The forbidden zones listed below are very specific. Race, religion, sexual orientation, health diagnoses, mental state, political stance, criminal history, ID numbers, bank card information, and real-time location — none of these can be written into memory. Even if the user explicitly asks to remember them, it's not allowed.

▲ Opus 5 original L678-L704

The screenshot divides unsavable content into three groups: protected attributes, sensitive information, and identifiable information. It also specifies several boundaries. Food allergies, vegetarianism, and halal diets can be saved as dietary restrictions; real-time location cannot be saved, but home or office addresses can; age can be saved, but age and birthday with a date cannot be kept together, because the two can be used to derive the date of birth.

It also does not allow wrapping sensitive information in a layer and then saving it.

▲ Opus 5 original L706-L723

The example given in the original text is: "I just turned 52, can't run because of diabetes, can you recommend some easier exercises?" Claude can record age 52 and that the user is interested in exercise plans. Diabetes cannot be written — not even a vague phrase like "dealing with a health issue" can be left.

Another example: "I have ADHD, so learning content needs to be broken into 15-minute segments." The preference for 15-minute learning segments can be saved; the ADHD diagnosis must be deleted.

Claude's rules allow retaining non-sensitive preferences, but the diagnosis cannot be wrapped in a layer and written into the file.

Date of birth gets its own separate entry. Age can be stored; a birthday with a specific date cannot. The two together can be used to reverse-engineer the date of birth, so only age can be kept in the file.

Deletion is also specified down to the specific operation. When the user says "forget X," Claude must delete the corresponding line directly — it cannot change it to "used to like X." If another memory entry was entirely derived from X, that entry must also be deleted together. Only when the user asks to forget an entire topic can memory_delete be called to delete the whole file; when the scope is unclear, first ask the user whether to delete one entry or all of them.

This section describes actual data handling rules: what information not to write, which parts should be retained, and what the scope is when the user requests deletion. The original text is concentrated in L644-L745.

Memory and Past Conversations Are Actually Two Separate Systems

The memory filesystem stores organized, established facts, such as the user's occupation, response preferences, and projects. The past conversations tool is responsible for searching raw chat logs — the two are used separately.

Opus 5 has two tools: conversation_search searches by topic keywords, and recent_chats searches by time.

The prompt also specifies when a search is mandatory. When the user says "my project," "the plan we set before," or "continue that Python project from last time," if the answer isn't in the current conversation or memory files, Claude must first search past chats and cannot directly reply "I can't see it."

▲ Opus 5 original L1116-L1128

When the current context doesn't show it, Claude must search first. conversation_search is suitable for project names and topic keywords; recent_chats is suitable for time ranges like "yesterday" or "last week."

Search keywords also have requirements. "What did we chat about yesterday regarding Chinese robots?" should search for Chinese robots, not discuss yesterday. The former might actually appear in old conversations; the latter is just describing the act of chatting.

▲ Opus 5 original L1132-L1139

After search results come back, Claude must also distinguish who said what. If an old chat only contains Claude suggesting Plan A, later it can only say "I suggested Plan A at the time." Only when the user's own message explicitly says "let's go with A" can it say "you chose Plan A."

When both a summary and the original record exist, prioritize the original record. Because the summary might compress Claude's suggestion and the user's response into a single sentence like "decided to go with A."

This section aims to prevent Claude from presenting its own past suggestions as decisions the user has already made. For search triggering and speaker verification rules, see original L1116-L1139.

Even When Connected to External Apps, It Can't Choose a Vendor for the User

L1067 begins discussing MCP Apps.

Claude can connect to third-party services like music, restaurant booking, ride-hailing, and food delivery. The title in the screenshot is [third_party_mcp_app] tools need opt-in: such consumer services, even when already connected, must first obtain user consent.

▲ Opus 5 original L1084-L1100

The example in the screenshot is: the user says "I need to call a car." This only expresses a need and does not specify a particular service provider. Claude must display available services through suggest_connectors and wait for the user to choose — it cannot directly pick one for them. The same applies when the user says "I need to leave in 20 minutes" — it cannot make the choice for the user.

Only three situations allow direct invocation: the user named a specific app; or the user just selected it moments ago; or the user has previously used this service for the same task or given a long-term instruction. In all other cases, Claude must first search, then present options for the user to choose.

E-commerce MCPs can only appear when the user names them; Claude cannot proactively recommend them. It also cannot deliberately withhold part of an answer, such as creating pressure by saying "you need to connect the app before we can continue." If the user ignored a recommendation once, don't pop it up again.

This set of rules leaves the choice to the user: Claude can execute actions like hailing a ride or ordering food, but it cannot decide which service gets the user's money and traffic. For complete rules, see original L1067-L1114.

For the Same Request, First Determine What Kind of Deliverable It Is

L1284 has a request_evaluation_checklist that specifies the order in which Claude selects tools and delivery methods before outputting visual content.

▲ Opus 5 original L1284-L1305

Step 0: does this request need visual content? If a plain text explanation can already clarify it, Claude answers directly in text. Only when it involves spatial relationships, data shapes, system structures, processes, or interactive tools does it proceed to the next step.

Step 1 checks already-connected MCP tools. If the user wants to draw an architecture diagram and the tool list happens to have a diagram tool, call it directly. The original text also specifically explains the matching criterion: look at the tool category, not which style Claude personally prefers.

Step 2 checks whether the user has explicitly requested a file. If the user says "create a file," "save to disk," or directly provides .md, .html, and an output path, Claude must write the file to the workspace.

If none of the first three steps resolve it, only then go to Step 3: use the Visualizer to generate SVG, diagrams, or interactive pages within the conversation. After selecting, deliver directly — the prompt also requires Claude not to recount this internal judgment process to the user.

The Visualizer here is an in-chat visualization tool defined within this prompt.

Word, PDF, PPT, and spreadsheets have an additional requirement. Before creating a file, Claude must first read the corresponding SKILL.md, then generate and check the file according to the操作方法 inside.

Claude first confirms whether the user wants text, external tool results, downloadable files, or in-chat visualization, then begins producing content. For the four-step sequence, see original L1284-L1305.

Seeing this, 2049 lines becomes understandable.

Every new capability Claude gains is one more place where something can go wrong.

It can save memories, so it might record information it shouldn't, or leave both outdated habits and new habits in the file simultaneously. It can search old chats, so it might present its own past suggestion as a decision the user already made. It can call external apps, so it might choose a service provider for the user without asking. It can generate diagrams and files, so it might hand an in-chat diagram to a user who explicitly asked for a downloadable file.

This prompt spends a large amount of space dealing with precisely these specific problems.

References:

• OPUS-5.md original in the CL4R1T4S repository, read on July 29, 2026. Third-party extraction, not an officially confirmed version from Anthropic.

• Anthropic: "Introducing Claude Opus 5", July 24, 2026.

• Anthropic: "Prompting Claude Opus 5".