Anyone else hitting permission prompts on every MEMORY/WORK write?

[javierburongarcia]

PAI stores session artifacts (PRDs, work logs, memory) under ~/.claude/MEMORY/WORK/. Claude Code hardcodes .claude/ as a protected directory with a separate "config-write" gate that fires on every write — even with all of these set:

• --dangerously-skip-permissions CLI flag
• permissions.defaultMode: "bypassPermissions" in settings.json
• Write in permissions.allow

The result: every PRD creation triggers "Do you want to create PRD.md?" with the Yes/No prompt. Every session, multiple times.

What I've confirmed

• The .claude/ gate is separate from the general permission system — the bypass flag doesn't override it
• Only .claude/commands, .claude/agents, .claude/skills are exempt
• Symlinks from inside .claude/ to outside paths still trigger it (path string check)
• Writes to paths outside .claude/ work perfectly with the bypass flag

Workarounds I'm considering

1. Moving MEMORY/WORK/ to a path outside .claude/ (e.g., ~/data/work/) and updating all Algorithm/hook references
2. Filing an upstream Claude Code issue requesting .claude/MEMORY/ as an additional exemption

Questions for the community

• Is anyone else running into this with their PAI setup?
• Has anyone already moved session storage outside .claude/? Any gotchas?

Environment: Claude Code 2.1.81, PAI 4.0.3, Linux VM

[javierburongarcia]

Seems to be a bug introduced by recent claude code versions, I am staying on 2.1.77 and seems to be working

[virtualian]

@javierburongarcia Sorry for the silence. Nothing's changed as far as I/Claude Code can see:

---

There's actually a whole constellation of open additionalDirectories bugs upstream — at least 7 distinct issues remain open in Claude Code:

• #35787 — settings.local.json not loaded in permissions (confirms your persistence finding from a different angle)
• #30064 / #37553 — skills not loaded from additionalDirectories
• #33268 — glob patterns don't match non-existent paths for create ops
• #40606 — project-approved dirs leak into all projects via global settings
• #22583 — CLAUDE.md not loading from additionalDirectories

This suggests additionalDirectories has deeper systemic issues beyond what your comment reports; the feature appears to be partially implemented across several code paths.

---

I think you're right about Anthropic making .claude/ a protected directory at the binary level. But that's not unreasonable, since it's "their" folder, and anyone else using it should expect the unexpected.

In theory, we can set PAI_DIR to move PAI out of ~/.claude, but I've not tried it (yet).

[javierburongarcia]

Thanks @virtualian! I will try that today and report back

[javierburongarcia]

Hi again @virtualian, did the migration and seems by setting PAI_DIR to an external folder the issue is fixed, I am now on CC latest stable version 84 and it seems that everything works as expected. I am doing further tests but I think this is a good fix for now

[brycemagera]

It sounds like Daniel has a fix that he's planning to push out soon as well.

[javierburongarcia]

It's working ok for me now but would love to hear an official fix so my pai system doesn't not drift too far from the official project, where did you hear about that?

[brycemagera]

Submitted a PR here to fix it!

[javierburongarcia]

Hi @brycemagera, i managed to fix it but it involves moving PAI outside of /.claude

[virtualian]

@javierburongarcia,

Could explain what and how?

Which folders did you move? PAI/? MEMORY/? Or a subset of the latter?

Did you just use $PAI_DIR? Or did you have to finesse this with additional changes or en vars?

[javierburongarcia]

In my PAI's words:

The ~/.claude → ~/.pai migration: what moved and how

The goal was a clean two-root architecture: ~/.claude stays as Claude Code's native home (it has to — CC owns it), while ~/.pai becomes PAI's data home. No more mixing AI system files with CC runtime files.

What moved to ~/.pai:

• PAI/ — the core AI system (Algorithm, USER/, CONTEXT_ROUTING, etc.)
• MEMORY/ — all state, learning, work tracking
• GUIDES/, PLANS/, VoiceServer/,

What stayed in ~/.claude:

• settings.json (CC owns this — it's the entry point)
• hooks/, commands/, agents/ (CC-native extension points)
• CLAUDE.md (CC loads this at startup)
• CC runtime files: claude.json, history.jsonl, cache/, etc.

it wasn't just $PAI_DIR:

1. settings.json env block — added "PAI_DIR": "/home/javi/.pai". This makes ${PAI_DIR} available in hook commands so they can find scripts in the new location.
2. CLAUDE.md path updates — hardcoded references like ~/.claude/PAI/Algorithm/... became ~/.pai/PAI/Algorithm/.... CLAUDE.md is still in ~/.claude (CC loads it), but it now points into ~/.pai for content.
3. Hook command strings — any hook using a path had to be updated from ~/.claude/... to ${PAI_DIR}/.... This is the most tedious part if you have many hooks.

Ive been running it for a couple of days and I can confirm that it is working well now

[mcardinali-data]

I created a $MEMORY_DIR and routed everything to Obsidian to get rid of this constant asking for permission thing. And now PAI is also able to do semantic search via Obsidian Smart Search.

[javierburongarcia]

Sounds like a good idea, can you give us a bit more details or a gist explaining the feature so we can test within our PAIs?

[afhaque]

Is the solution here still just to stay on the older version of Claude Code?

[javierburongarcia]

I think so as cc has hardened .claude folder. What I did was to decouple .pai from .claude and things are working well since them, I have upddated cc to the latest version and it is working well

[pybe]

So is the hope that if we put everything to .pai that we can just keep everything separate and PAI stands alone from Claude or anything else that we use. It should be one consolidated system of stuff that's flexible between solutions like PI, et cetera?

[javierburongarcia]

Hi, I have to say that I went back to a single .claude folder as I wanted to align with PAI 5 release. I was hoping that this was solved in some way in the new release but I dont think it is. Created a thread hoping that someone could point me to the right direction, I am puzzled that only few people are having similar issues to be honest

What I found out is that if you use auto-mode most of the permission prompts are gone but you need opus for auto-mode #1123 My guess is that most users are burning tokens like crazy using only Opus with their PAIs and their 20xMax subscriptions :-D

Anyway, I hope @danielmiessler or some PAI experienced users will be able to point us to the right direcion here

[brycemagera]

V5 and PR 1136 fixes things.

[javierburongarcia]

Yes!

EDITED: still not working for me, it ask for permissions when creating new skills, is this expected?

[brycemagera]

Hmm, I'd have to review how Daniel built SmartApprover to be sure on new skills. I can say that on my personal computer, my work computer, and a colleague's computer this is working wonderfully for us.

[danielmiessler]

Hey @javierburongarcia, thanks for raising this, and sorry it sat for a while.

We're changing how LifeOS ships. Instead of cloning a full ~/.claude directory and running it as a complete system, LifeOS is becoming a skill you install through an agentic installer. The installer hands integration to your own AI, which reads your actual machine (your OS, your paths, your harness) and wires the hooks and system prompt in where they belong.

That's aimed right at what you hit here. The old "one directory, one layout, hope it matches your setup" approach is exactly what broke for so many people, and the new model should handle it far better because your AI does the integration per machine instead of us guessing.

So we're closing this in prep for that release. If it still bites you once the skill-based version is out, reopen or file a fresh one and we'll jump on it. Appreciate you taking the time.