Race condition when multiple Claude Code windows write to tasks.json

[bjcoombs]

Problem

When multiple Claude Code windows (separate processes) access Task Master simultaneously, the JSON file can get corrupted or work that Task Master claims to have saved is lost.

Root Cause

The readJSON() and writeJSON() functions in scripts/modules/utils.js had no file locking mechanism:

• Multiple processes could read the same file simultaneously
• Each process would make changes to its copy
• When writing, later writes would overwrite earlier ones, losing updates

Additionally, the _rawTaggedData snapshot pattern caused stale data issues - a snapshot taken at read time could become outdated by the time the write occurred.

Impact

• Data loss when multiple Claude Code sessions work on the same project
• Corrupted tasks.json file
• Lost task updates, status changes, and subtask modifications

Solution

Implemented in PR #1566:

• Cross-process file locking using proper-lockfile (async) and custom lock files with exclusive wx flag (sync)
• Atomic writes using temp file + rename pattern
• Re-read file inside lock to get current state
• Stale lock detection and automatic cleanup (10-second timeout)

Reproduction Steps

1. Open multiple Claude Code windows on the same project
2. Have both windows make Task Master operations simultaneously (e.g., set-status, update-subtask)
3. Observe that some changes are lost or file becomes corrupted

[ilmarioranen]

I hope this is handled as a high-priority because this lack of tasks.json locking and corruption risk is very real, and not just limited to multi claude code instances.

I have witnessed tasks.json corruption when I simply have several different IDE:s/CLI:s etc connected to the same project, running various agents in parallel. Eg. Cursor, Antigravity, Codex, VSCode, Kiro .... Antigravity especially likes to corrupt stuff, it wiped my tasks.json on the first day of usage. Antigravity might lack some internal safeguards.

I like that task-master keeps it simple with tasks.json instead of database dependencies, but without some proper locking mechanism that simplicity will lead to chaos, especially in setups where task-master stuff is not version controlled ( gitignored etc).

[bjcoombs]

I've raised a pr fix for it. So hopefully get it merged in soon.

[Crunchyman-ralph]

Resolved in 0.42.0