Concurrent PAI Sessions: Shared State Has No Concurrency Protection

[virtualian]

The Problem

PAI adds significant shared mutable state on top of Claude Code's ~/.claude/ directory — memory files, task/team JSON, CLAUDE.md template rendering, learning signals, Algorithm state. None of it has file locking, atomic writes, or any concurrency protection.

Running multiple PAI-enabled CC sessions simultaneously can corrupt or silently lose data. This is compounded by the fact that Claude Code itself has unresolved concurrency bugs in its own shared files.

This topic has surfaced repeatedly in this community from different angles — hook concurrency, session lifecycle, context integrity, multi-machine sync, parallel agents — but has never been mapped as a single systemic problem.

PAI-Specific Shared Mutable State at Risk

Resource	Path	Write Pattern	Risk
Memory files	MEMORY/LEARNING/, MEMORY/RELATIONSHIP/, etc.	Read → modify → write-back (full file)	MEDIUM — Two sessions updating the same memory file → last-write-wins, earlier edits silently lost
Task files	~/.claude/tasks/{team}/	Read JSON → modify → write JSON	HIGH — Classic read-modify-write race. Corrupted JSON, phantom tasks, lost updates
Team config	~/.claude/teams/{team}/config.json	Read JSON → modify → write JSON	HIGH — Same as tasks. Concurrent member registration could corrupt the members array
CLAUDE.md	~/.claude/CLAUDE.md	Template rendering overwrites entire file	MEDIUM — If a session re-renders CLAUDE.md from template while another session is reading it, the reader gets partial content
Session state	PAI/USER/PROJECTS/, learning signals, etc.	Append or overwrite	MEDIUM — SessionProgress writes, learning signal captures, etc. can collide
Algorithm state	Algorithm processing writes to various state files	Read → process → write	LOW — Usually single-session, but if two sessions both enter Algorithm mode simultaneously, state could be inconsistent

Prior Discussions in This Community

This problem has been hit from multiple angles here, each addressed in isolation:

Issues

• #170 (closed, won't-fix) — "Concurrency issues again, seems to happen with hooks?" — User hit API Error: 400 due to tool use concurrency issues when PAI hooks fired concurrently. Maintainer response: "This is a Claude Code platform limitation, not something PAI can fix." The user had independently added a directive forcing sequential tool use as a workaround.
• #510 (closed) — "[PAI-UI][Server] Session manager for tracking active sessions" — Spec for a SessionManager class with concurrent session limits (max 5), cleanup, and lifecycle tracking. Was part of a PAI-UI server batch — closed with that effort but the underlying need (session awareness) was never shipped to CLI users.
• #100 (closed) — "Duplicate SessionStart events" — IDE extension fires two SessionStart events with different session IDs for a single launch, causing duplicate API calls. Symptom of the same lack of session-level isolation.

Discussions

• #154 — "400 Concurrency Errors" — PAI's hook-heavy architecture triggers CC's concurrency error when multiple tool calls queue before previous results arrive. The error cascades: hook output replays as fake user messages, triggers runaway loops, corrupts execution state.
• #652 — "Session Safety Net" — Addresses orphaned sessions on shared PAI VMs: no idle timeout, no max concurrent sessions, no process management in CC. Includes evidence of CC memory leaks in idle sessions (single session growing to multi-GB).
• #792 — "Upstream Claude Code bugs affecting PAI session context" — CC's context compaction destroys PAI's hook-injected context. Directly affects multi-session scenarios where compaction fires at different times, causing sessions to diverge in behavior.
• #188 / #384 — "Running PAI Across Multiple Machines" — Users on 3-4 machines hit path conflicts, hook errors, and state sync issues. The multi-machine problem is a superset: if state files aren't safe for concurrent local access, they aren't safe for cross-machine sync either.
• #725 — "Algorithm CLI — Loop Mode & Parallel Agents" — Parallel agents each spawn their own CC session, multiplying all shared-state risks.

Upstream Claude Code Bugs (Open, Unfixed)

PAI inherits all of these — they affect the base layer:

CC Issue	Problem
#29217	.claude.json corrupted by concurrent writes — 165 corrupted backups in 40 min
#26964	JSONL cross-session contamination — up to 76.6% events written to wrong session file
#24317	OAuth refresh token race — multiple sessions fight over shared credentials
#28093	MCP calls routed to wrong server when sessions run concurrently
#27380	Permission bypass mode resets when switching between sessions
#16311	Feature request for per-session workspace isolation (unfulfilled)

Safety Tiers for Concurrent Use

Safe

One PAI session + one or more vanilla CC sessions in different directories — minimal shared state beyond .claude.json and credentials (CC upstream risk only).

Risky

Two PAI sessions in different directories — both write to shared MEMORY/, both could enter Algorithm mode, both could update learning signals.

Dangerous

Two PAI sessions in the same directory — all of the above plus project-scoped CLAUDE.md, session history, and project memory all collide. Two PAI sessions using agent teams — task and team JSON files have no locking whatsoever.

Possible Mitigations

Short-term (documentation + detection):

• Document the safety tiers above so users know the constraints
• Add a SessionStart check that warns if another PAI-enabled claude process is detected

Medium-term (defensive writes):

• Atomic writes (write to temp file → rename()) for all PAI JSON and markdown files — process-safe on POSIX
• Advisory file locking (flock) around read-modify-write cycles for task/team files
• Append-only patterns where possible instead of read-modify-write

Long-term (architectural):

• Wait for CC upstream per-session isolation (anthropics/claude-code#16311)
• Consider a lightweight PAI state server (the VoiceServer pattern) that serializes all writes
• Session-scoped memory and task namespacing

Current Workaround

Run only one PAI session at a time. Secondary sessions should be vanilla CC (claude without PAI hooks/context) in separate project directories.

---

Researched and written by Claude (Opus 4.6), @virtualian's Viki, and Ian Marr.

[chrisglick]

Great research! I've been multi-term'ing with 3 PAI in separate directories and notice a lot more claude.json corruptions (upstream). This seems like a semi-solved issue with your mitigation suggestions. I hope we can solve this at the root.

[virtualian]

Claude + PAI is very good at this :-). The trick is to make sure they thoroughly research the background.

[mvanders]

Regarding multi-device, I stumbled upon Happy Engineering (https://happy.engineering/), but does not seem to get updated... :-(
Besides single-user, multi-device, there is also multi-user... I just watched Daniel's new video on lattice. I wonder how he will get from PAI (single user) to LATTICE (multi-user)?

[punkrokk]

I can't wait to experience this.

[Drizzt321]

This is definitely something I'm seeing some. I heavily multi-session. Something that my PAI had a thought of, was to do a flock for any writes to those files. Probably exists on Mac (given Unix heritage), and on Windows under WSL2, although I don't think core Windows outside of that. Or it has it's own similar mechanism, but not as easily shared code, necessarily.

Another thought I just had, although not usable everywhere, but on Linux, potentially using D-Bus