You opened Project → Edit instructions, pasted a new ruleset (“reply in English only,” “never propose Python”), hit save — and the model still answers in Chinese with Python code. Project Instructions are not magic; they live in a stack with global Custom Instructions, the current chat’s running context, and Project Files. When a higher-priority layer contradicts the new rule, the new rule loses silently. Also: Instructions have a character cap, and the silent truncation problem catches many people by surprise.
Common causes
Ordered by hit rate, highest first.
1. Existing chat threads still carry pre-update behavior
The most common cause. The model in the current chat keeps mirroring whatever it was doing before you edited Instructions, because the chat’s running context is “winning” against the freshly saved rule.
How to spot it: Open a NEW chat in the same Project, run the same prompt — if the new rule is now followed, the old chat’s history was the override.
2. Custom Instructions (account-level) conflict with Project Instructions
Settings → Personalization → Custom Instructions applies to every Project. If your Custom Instructions say “always include Python examples” and your new Project Instruction says “never suggest Python,” the model resolves the conflict unpredictably.
How to spot it: Temporarily clear Custom Instructions and rerun the prompt — if the Project rule now sticks, that was the conflict.
3. Instructions silently truncated at the char limit
Project Instructions have a soft cap (typically 1500-2500 characters depending on plan). If you pasted 4000 characters, the back half may be dropped without warning. Any rule sitting past the cut-off is invisible.
How to spot it: Ask in the Project “repeat your Project Instructions verbatim, including any line about Python” — if it cannot quote the line, it was truncated.
4. New rule contradicts the Project Files
If a file uploaded into Project Files contains Python code throughout, the model treats that as strong context evidence and may keep producing Python despite a rule against it.
How to spot it: Remove the Python-heavy file temporarily and rerun — rule sticks = file was outvoting the rule.
5. You edited the wrong Project
You have 5 Projects with similar names. You edited “Q2 Campaign” but you are chatting in “Q2 Campaign (copy)” — the Instructions update never landed where you are testing.
How to spot it: From the chat sidebar, click the Project name and verify it matches the one you just edited.
6. The save did not commit (network blip, modal closed early)
Save sometimes silently fails if you closed the modal too fast or hit save while offline. The Instructions field reopens with old content.
How to spot it: Reopen Project → Edit instructions — if the new text is not there, save never happened.
Before you start
- Confirm you saved by reopening the Instructions modal — eyeball the actual stored text.
- Note your Project name precisely; if duplicates exist, suffix one to disambiguate.
- Decide whether your rule is a hard constraint (model must obey) or a soft preference — wording matters.
Info to collect
- Full Instructions text (screenshot the modal after save).
- Custom Instructions text (Settings → Personalization).
- List of files in Project Files.
- Exact prompt + reply where the rule was ignored.
- Whether it fails in a new chat or only in the existing chat.
- Subscription tier + workspace (Personal / Team / Enterprise).
Shortest fix path
Ordered by ROI. Steps 1 and 2 fix the majority.
Step 1: Open a fresh chat in the same Project
Existing chats keep their pre-update context. The fastest sanity check:
Project → New chat → first prompt:
"State the first rule from this Project's Instructions verbatim,
then answer: <your test question>"If the new rule shows up, you are done for fresh work. Old chats remain affected.
Step 2: Rewrite Instructions as short hard constraints, not stories
Most “ignored Instructions” are actually “vague Instructions.” Convert:
Bad (paragraph form):
"This project is about our enterprise SaaS dashboard. The team
historically prefers TypeScript and we sometimes use Python for
scripts but generally try to standardize on TypeScript when
possible because of long-term maintenance."
Good (hard constraint form):
Constraints (always follow):
- Output language: English only
- Tech stack: TypeScript only — never propose Python
- Tone: concise, no apologies
- Always cite specific file names when referencing Project FilesBullets, imperatives, “always / never” — these are obeyed more reliably than narrative.
Step 3: Check Custom Instructions for conflicts
Settings → Personalization → Custom Instructions
→ Read both fields carefully
→ Remove anything that contradicts your new Project rule
→ Or rewrite as "default preferences (overridable by per-Project rules)"When Project and Custom collide, the model picks one — explicit “overridable” framing helps Project win.
Step 4: Verify Instructions are not truncated
In a Project chat, ask:
"Print your Project Instructions verbatim from the first line
to the last. Do not summarize."Compare the output to what you saved. Anything missing = truncated. Shorten by removing background prose and keeping only rules.
Step 5: Reduce Project Files that fight the rule
If you said “TypeScript only” but the Files panel has 8 Python files, the corpus outvotes the rule. Either:
- Remove the Python files, or
- Add to Instructions: “Files in this Project may contain Python for historical reasons — never suggest Python in replies.”
Step 6: Re-save Instructions explicitly
If you suspect the save didn’t commit:
Project → Edit instructions
→ Cut all text → paste back → Save
→ Close modal → wait 5s → reopen modal
→ Confirm text is present
→ Then test in a new chatStep 7: For repeated ignore patterns, add an enforcement preamble
Some rules need extra weight. Prepend to Instructions:
ENFORCEMENT: Before every reply, internally check whether any
rule below would be violated. If yes, revise the reply before
sending. Rules:
- <rule 1>
- <rule 2>The self-check preamble materially improves rule adherence.
How to confirm the fix
- New chat in the Project → first prompt asks for the new rule verbatim → exact quote back.
- Run 3 prompts that previously violated the rule — all 3 now comply.
- Have a teammate open the Project in their account and rerun — same compliance = rule lives in the Project, not just your local state.
Common pitfalls
- Editing Instructions while leaving an old chat open and assuming it will retroactively comply — chats freeze their context.
- Using soft language (“prefer,” “generally”) and expecting hard enforcement.
- Pasting 5000 characters and missing the silent truncation cutoff.
- Saving from the duplicate Project (“Q2 Campaign (copy)”) instead of the live one.
- Stacking 15 rules and burying the most important one at the bottom — order matters; put critical rules first.
FAQ
Q: What is the actual character limit for Project Instructions? A: It varies by plan and changes over time; Plus is typically 1500-2500 characters as of 2026. Always verify by quoting Instructions back from the model.
Q: Do Project Instructions get fed at every turn? A: Yes, the Instructions are included with each request inside the Project. But if Custom Instructions or chat history conflict, the model may not honor them.
Q: Will deleting and recreating the Project preserve files? A: No. Files are bound to the Project. Download first, then recreate.
Q: Can I version-control my Instructions?
A: Not built-in. Keep a local instructions.md for each Project and paste-and-replace when iterating.
Q: How quickly does an Instructions change take effect? A: Immediately for new chats. Existing chats may keep prior behavior until you start a new chat or explicitly tell the model to discard the old context.
Related reading
- ChatGPT Project context bleeds from old chats
- ChatGPT project instructions ignored
- ChatGPT project files not referenced
- ChatGPT Projects
- ChatGPT Projects advanced workflow
Tags: #ChatGPT #Troubleshooting #chatgpt-projects #project-instructions