Claude Project Instructions Ignored: Why & How to Fix

Your Claude Project says "no emoji" but answers still have them. Project instructions are soft constraints — here is how to make Claude actually follow them.

You spell it out in your Claude Project’s instructions: “no emoji in responses,” “TypeScript only, never JavaScript,” “answer in English, never Chinese.” Two turns in, emoji are everywhere, code samples are JS, and one reply switched to Chinese. This is not Claude actively ignoring you. Project instructions are soft constraints to the model, not hard rules, and the way you phrase them decides whether they survive a real conversation.

Fastest fix (works for most people): rewrite each rule so a stranger could objectively tell whether a given answer broke it (Never output emoji characters instead of be professional), split the instructions into MUST / MUST NOT / Style blocks, and keep the whole thing under about 500 words. Mechanically checkable rules are followed far more often than vague ones. The rest of this page is the full diagnosis and the deeper fixes when that is not enough.

Mental model: your project instructions get prepended to the system prompt on every chat in that project. The model weighs them, but when the current prompt implicitly or explicitly conflicts, or the rule is too vague to verify, it follows the most recent, most specific signal. That is instruction drift.

Where project instructions actually live (June 2026)

If you are not even sure your instructions are saved in the right place, check this first. Projects are now available on every plan, including Free (Free accounts can keep up to 5 projects), so the steps are the same for everyone:

  1. Open the project on claude.ai.
  2. In the project knowledge panel on the right side, click Set project instructions.
  3. Type the rules, then click Save instructions.

Two things people get wrong here:

  • Your personal profile instructions (Settings, then Profile) and your project instructions are different boxes. A rule in one does not apply where you think the other lives.
  • On Team and Enterprise plans there is now a third, higher layer: organization instructions (set by an admin under Organization settings, then Organization and access, max 3,000 characters). Per Anthropic’s docs, “when both are set, organization instructions take precedence,” and “if an individual instruction directly contradicts an organization instruction, Claude favors the organization-level instruction.” If your team’s answers keep ignoring a project rule, an org-level rule may be quietly overriding it — ask your admin.

Common causes

Ordered by hit rate, highest first.

1. Rules are too abstract — the model cannot judge a violation

“Be professional.” What counts as professional? “Don’t be too verbose.” How long is too long? Subjective words leave interpretation space, and drift is inevitable.

How to spot it: read your rules and ask, “could a new contractor objectively decide which answers violated this?” If not, this is your problem.

2. The current prompt implicitly conflicts

The rule says “output TypeScript,” but you ask “how would I change this JS snippet?” The model follows the prompt because it inferred you wanted JS for this turn.

How to spot it: review recent prompts. Any hints that you implicitly wanted the banned format, language, or style?

3. Long context dilutes the rules

Instructions stay in the system prompt, but in a long chat Claude compacts older turns to fit the context window, and rules that look low-value to the compactor get paraphrased away. Most attention also lands on recent dialogue, so early rules lose force. (Counterintuitively, this means a hyper-specific rule can survive compaction better than a vague one, because the compactor is less likely to treat it as throwaway.)

How to spot it: violation in turn 1 means the rule itself is broken; violation only after turn 20 or so means context dilution. Starting a fresh chat in the same project and re-testing turn 1 isolates this cleanly.

4. Rules contradict each other

“Explain every step in detail” plus “keep answers concise.” The model must pick one, and it is not always the one you wanted.

How to spot it: read the full instructions and look for direct opposites like “must be detailed” versus “must be brief.”

5. Ambiguous negations

“Don’t not write tests” (double negative) or “avoid too many technical terms” (vague hedge). Models parse these badly.

How to spot it: search for “don’t not,” “avoid too,” “less of,” “try not to.”

6. Instructions are too long

The project box accepts roughly 8,000 characters (about 2,000 words), but capacity is not the goal. Long instructions drown key rules in decoration, and adherence is most reliable when the active system prompt stays well under a few thousand tokens. If the first 200 words are “our company is focused on…” the real rules are pushed down.

How to spot it: paste the instructions into a word counter. Over 500 words is usually a signal to cut.

Quick diagnosis table

SymptomMost likely causeGo to
Broken in turn 1 of a fresh chatRule is vague or self-contradictoryFix steps 1, 2
Followed early, drifts after ~20 turnsContext dilution / compactionFix step 4, then start a new chat
Only breaks when you reference banned formatImplicit prompt conflictFix step 4 (restate per chat)
Team-wide, no project change fixes itOrg instruction overridingAsk admin (see section above)
Works in API but not on claude.ai (or vice versa)Wrong layer / unsynced settingPut hard rules in system (fix step 6)

Shortest path to fix

Step 1: turn abstract rules into hard ones

❌ "Be professional"
✅ "Never emit emoji characters; never end sentences with !"

❌ "Don't be too verbose"
✅ "No response over 300 words; if longer is required, use bullets"

❌ "Use TypeScript"
✅ "All code blocks must be tagged ts or tsx; never .js / .jsx;
    if user pastes JS, first say 'I'll convert to TS', then answer"

Observable, mechanically verifiable rules are followed far more often.

Step 2: use a structured template with XML-tagged hard rules

Claude was trained on XML-structured prompts and follows multi-part instructions more reliably when the non-negotiable parts are tagged, so wrap the hard rules explicitly:

<critical_rules>
- Never use emoji
- Always respond in English
- Code is always TypeScript, never JavaScript
</critical_rules>

# Soft preferences

- Prefer functional patterns over OOP
- Use named arguments

# Tone

- Direct, no hedging
- No filler intro ("Great question!")

The explicit hard/soft split lets the model satisfy the critical block first and treat the rest as preferences.

Step 3: trim to 300-500 words

Cut:

  • Company or project background, unless it actually affects answers
  • Politeness (“please,” “thank you”)
  • Restated rules (“must,” “never forget to”)
  • Decorative paragraphs

Keep only behavior rules.

Step 4: restate the 1-2 most critical rules at chat start

First message:

Reminder: all code must be TypeScript, no emoji.
My question now is ...

Most recent plus most specific equals highest priority for the model. This is the single most effective fix for drift in long chats.

Step 5: call out violations and demand acknowledgment

Your last response contained emoji. Confirm you saw the rule
"Never use emoji" and explain why you violated it. Then redo
the answer.

Forcing the model to recite the rule sharply increases compliance on the next turn.

Step 6: for API use, put critical rules in system, not Projects

If you call the API rather than web Claude, put hard rules in the system field — it carries more weight than chat-level context and is not subject to the same compaction. Wrap them in <critical_rules>...</critical_rules> tags for stronger adherence. Note that a system prompt set in the API does not appear on claude.ai, and project instructions set on claude.ai do not flow into the API — they are separate surfaces, so set the rule on the surface you are actually using.

How to confirm it’s fixed

  1. Start a brand-new chat inside the project (not a continuation — old context carries old behavior).
  2. Send a prompt that previously triggered the violation, ideally one that gently tempts the banned behavior (e.g., paste a JS snippet when the rule is TypeScript-only).
  3. Check turn 1 against your now-objective rule. If it passes, push to ~10-15 turns to confirm it holds under length.
  4. If it still breaks in turn 1, the rule is still ambiguous or contradicts another rule — return to Steps 1 and 2. If it only breaks deep in a long chat, lean on Step 4 (restate per chat).

FAQ

Why does Claude follow my instructions at first and then forget them? Long chats get compacted to fit the context window, and rules that look low-value to the compactor get paraphrased or dropped, while recent turns dominate the model’s attention. Restate the critical rule at the start of each chat, or start a fresh chat when drift sets in.

Do project instructions override my personal/profile instructions? They stack rather than strictly override. The clear precedence Anthropic documents is at the org level: on Team and Enterprise, organization instructions win over individual instructions when they conflict. Within your own account, keep project and profile rules from contradicting each other so the model is not forced to choose.

Is there a character limit on project instructions? Anthropic does not publish an official figure, but the project box accepts roughly 8,000 characters (about 2,000 words) as of June 2026. More room is not better — adherence is most reliable when the active rules stay short, so aim for 300-500 words.

My whole team’s answers ignore a project rule — what’s different? Check for an organization instruction. On Team and Enterprise plans, admins set org-wide instructions (Organization settings, then Organization and access) that take precedence over project and individual ones. A conflicting org rule will silently override yours.

Will instructions work the same in the API as on claude.ai? No. They are separate surfaces. An API system prompt does not show up on claude.ai, and claude.ai project instructions do not reach the API. Put the rule on whichever surface your requests actually go through.

Prevention

  • Split instructions into three blocks: MUST / MUST NOT / Style. Keep each to a few short lines.
  • Every rule must be observable and mechanically verifiable — abstract rules will not be followed.
  • Keep total length under ~500 words; cut redundant verbiage.
  • Restate critical rules at the start of each chat (one short sentence).
  • When the model violates a rule, name it explicitly rather than glossing over it.
  • Review instructions monthly based on which ones actually get followed.

Tags: #Claude #Troubleshooting