Issue Station
Sign In
Tools hereToolbox

claude-code - ✅(Solved) Fix [BUG] ENOENT on mkdir of per-session tasks dir when running parallel Claude Code sessions [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#49512•Fetched 2026-04-17 08:39:01
View on GitHub
Comments
0
Participants
1
Timeline
7
Reactions
0
Author
ekatchourekatchour
Participants
ekatchourekatchour
Timeline (top)
labeled ×5cross-referenced ×1referenced ×1

When running multiple Claude Code sessions in parallel as the same user, sessions intermittently crash with:

Error: ENOENT: no such file or directory, mkdir '/tmp/claude-999/-home-//tasks'

This did not happen with previous versions of Claude Code. The per-session tasks/ subdirectory layout appears to be new, and cleanup from one exiting session seems to race with directory creation in a sibling session.

Environment

  • Claude Code version: 2.1.112 (Claude Code)
  • OS: Linux 6.17.13-2-pve
  • Shell: bash/zsh
  • User UID: 999
  • Running multiple claude sessions concurrently in different working directories (and/or the same one)

Error Message

Error: ENOENT: no such file or directory, mkdir '/tmp/claude-999/-home-......

Actual

Parent directory under /tmp/claude-<uid> is removed while a concurrent session needs it, causing the next mkdir to fail.

Root Cause

When running multiple Claude Code sessions in parallel as the same user, sessions intermittently crash with:

Error: ENOENT: no such file or directory, mkdir '/tmp/claude-999/-home-//tasks'

This did not happen with previous versions of Claude Code. The per-session tasks/ subdirectory layout appears to be new, and cleanup from one exiting session seems to race with directory creation in a sibling session.

Environment

  • Claude Code version: 2.1.112 (Claude Code)
  • OS: Linux 6.17.13-2-pve
  • Shell: bash/zsh
  • User UID: 999
  • Running multiple claude sessions concurrently in different working directories (and/or the same one)

Fix Action

Fixed

PR fix notes

PR #412: fix: bump CLI versions — codex 0.121.0, gemini 0.38.1, copilot 1.0.30, cursor 2026.04.15

Description (problem / solution / changelog)

Summary

Bump pinned CLI versions in Dockerfiles after investigating latest releases and upstream bug trackers.

Changes

DockerfileCLIOldNewNotes
Dockerfile.codex@openai/codex0.120.00.121.0No CLI-specific regressions; open bugs are VS Code extension/desktop app only
Dockerfile.gemini@google/gemini-cli0.37.20.38.1Clean — zero open bugs with bug label
Dockerfile.copilot@github/copilot1.0.251.0.30No public issue tracker (repo 404); low risk
Dockerfile.cursorCursor Agent CLI2026.04.14-ee4b43a2026.04.15-dccdccdVersion from official install script; ships with Cursor 3.1 (Apr 13)

NOT updated (intentionally)

DockerfileCLIPinnedLatestWhy
Dockerfilekiro-cli2.0.02.0.0Already latest
Dockerfile.claude@anthropic-ai/claude-code2.1.1042.1.112⚠️ Too risky for container workloads — see below
Dockerfile.opencodeopencode-ai1.4.61.4.6Already latest

claude-code risk assessment

  • #49512 (2.1.112): ENOENT race condition on mkdir of per-session tasks dir when running parallel sessions — labeled regression + platform:linux. Directly impacts openab which runs containers with concurrent sessions.
  • #49503 (2.1.111): settings.json model preference silently ignored — sessions default to Opus 4.7 instead of pinned model.
  • #47648 (2.1.105+): Auth token paste broken on Linux — closed as "not planned" (the original issue that triggered PR #333 revert to 2.1.104).

Recommendation: stay on 2.1.104 until upstream resolves the parallel session race condition.

How to verify

# Check latest versions
curl -fsSL https://prod.download.cli.kiro.dev/stable/latest/manifest.json | jq -r .version
npm view @openai/codex version
npm view @anthropic-ai/claude-code version
npm view @google/gemini-cli version
npm view @github/copilot version
curl -fsSL https://cursor.com/install | grep "CURSOR_VERSION\|DOWNLOAD_URL" | head -2
npm view opencode-ai version

Ref: #326, #333

Changed files

  • Dockerfile.codex (modified, +1/-1)
  • Dockerfile.copilot (modified, +1/-1)
  • Dockerfile.cursor (modified, +1/-1)
  • Dockerfile.gemini (modified, +1/-1)

Code Example

Error: ENOENT: no such file or directory, mkdir '/tmp/claude-999/-home-......

  ### Actual                                                                                                                                 
  Parent directory under `/tmp/claude-<uid>` is removed while a concurrent session needs it, causing the next `mkdir` to fail.
RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing issues and this hasn't been reported yet
  • This is a single bug report (please file separate reports for different bugs)
  • I am using the latest version of Claude Code

What's Wrong?

Description

When running multiple Claude Code sessions in parallel as the same user, sessions intermittently crash with:

Error: ENOENT: no such file or directory, mkdir '/tmp/claude-999/-home-//tasks'

This did not happen with previous versions of Claude Code. The per-session tasks/ subdirectory layout appears to be new, and cleanup from one exiting session seems to race with directory creation in a sibling session.

Environment

  • Claude Code version: 2.1.112 (Claude Code)
  • OS: Linux 6.17.13-2-pve
  • Shell: bash/zsh
  • User UID: 999
  • Running multiple claude sessions concurrently in different working directories (and/or the same one)

What Should Happen?

Sessions should not interfere with each other's tmp directories. Cleanup of one session should not delete shared parents still in use by others.

Error Messages/Logs

Error: ENOENT: no such file or directory, mkdir '/tmp/claude-999/-home-......

  ### Actual                                                                                                                                 
  Parent directory under `/tmp/claude-<uid>` is removed while a concurrent session needs it, causing the next `mkdir` to fail.

Steps to Reproduce

  1. Start 2–3 claude sessions in parallel in different terminals.
  2. Let one session exit (normally or via timeout).
  3. Continue using or start another session shortly after.
  4. Observe ENOENT on /tmp/claude-<uid>/.../tasks.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

2.1.112

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Terminal.app (macOS)

Additional Information

No response

extent analysis

TL;DR

The issue can be mitigated by ensuring that the cleanup process of one Claude Code session does not interfere with the directory structure needed by concurrent sessions.

Guidance

  • Verify that the issue is indeed caused by the race condition between session cleanup and directory creation by checking the timing of session exits and starts.
  • Consider implementing a locking mechanism or a more robust directory management system to prevent concurrent sessions from interfering with each other's tmp directories.
  • Check if there are any configuration options or environment variables that can be adjusted to change the behavior of the tmp directory cleanup.
  • Test the issue with different user IDs to see if the problem is specific to the user ID 999.

Example

No code snippet is provided as the issue seems to be related to the internal workings of the Claude Code application and its interaction with the operating system.

Notes

The issue appears to be a regression introduced in version 2.1.112, and the exact cause may require further investigation into the application's codebase. The provided information suggests a race condition, but the root cause may be more complex.

Recommendation

Apply a workaround, such as using a different directory structure or implementing a locking mechanism, as the issue seems to be related to the application's internal logic and may require a code change to fully resolve.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#cache issue#memory leak#API versioning#request timeout

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING