Thread rename fails with ENOENT error: file path resolves to 'n/a'

Status Fixed / completed
Reported on v2.0.73
Maintainer reply ✓ Yes — bcherny
Activity 9 comments · opened Dec 19, 2025 · closed Aug 20, 2026
💡 Likely answer: A maintainer (bcherny, collaborator) responded on this thread — see the highlighted reply below.

Description

When attempting to rename a Claude Code thread, the operation fails with an ENOENT error because the file path resolves to the literal string 'n/a' instead of an actual file path.

Error Message

This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason:
Error: ENOENT: no such file or directory, open 'n/a'
    at openSync (unknown)
    at <anonymous> (/$bunfs/root/claude:12:1277)
    at sW (/$bunfs/root/claude:11:8463)
    at appendFileSync (/$bunfs/root/claude:12:1200)
    at zu_ (/$bunfs/root/claude:1038:3185)
    at w6R (/$bunfs/root/claude:1039:78)
    at w6R (/$bunfs/root/claude:1039:214)
    at <anonymous> (/$bunfs/root/claude:3915:471)
    at <anonymous> (/$bunfs/root/claude:3915:522)
    at WT (/$bunfs/root/claude:4713:7)

Steps to Reproduce

  1. Open Claude Code CLI
  2. Have an existing thread/conversation
  3. Attempt to rename the thread

Expected Behavior

Thread should be renamed successfully and the new name should persist.

Actual Behavior

Operation fails with ENOENT error. The code appears to be trying to open a file at path 'n/a' which suggests a variable holding the metadata file path is not being properly initialized or resolved.

Impact

  • Unable to rename threads to meaningful names
  • Makes it difficult to track and organize important conversations
  • Thread names remain as auto-generated/hard-to-parse identifiers

Environment

  • OS: macOS (Darwin 24.6.0)
  • Claude Code Version: 2.0.73

Additional Context

The thread data itself is stored correctly in ~/.claude/projects/<project-path>/<session-id>.jsonl, but the thread naming/metadata storage mechanism appears to have a bug where the file path variable is not being set correctly before the file operation.

---
🤖 Generated with Claude Code

View original on GitHub ↗

9 Comments

marcoscale98 · 8 months ago

same issue

dkampien · 8 months ago

same here

CyberMew · 8 months ago

Same here, still happening on v2.0.76 in VSCode terminal while trying to rename session name.

node:fs:561
  return binding.open(
                 ^

Error: ENOENT: no such file or directory, open 'n/a'
    at Module.openSync (node:fs:561:18)
    at file:///Users/user/.nvm/versions/node/v22.17.1/lib/node_modules/@anthropic-ai/claude-code/cli.js:9:1210
    at oI (file:///Users/user/.nvm/versions/node/v22.17.1/lib/node_modules/@anthropic-ai/claude-code/cli.js:8:8084)
    at Object.appendFileSync (file:///Users/user/.nvm/versions/node/v22.17.1/lib/node_modules/@anthropic-ai/claude-code/cli.js:9:1139)
    at D12 (file:///Users/user/.nvm/versions/node/v22.17.1/lib/node_modules/@anthropic-ai/claude-code/cli.js:1110:3100)
    at r81 (file:///Users/user/.nvm/versions/node/v22.17.1/lib/node_modules/@anthropic-ai/claude-code/cli.js:1111:68)
    at file:///Users/user/.nvm/versions/node/v22.17.1/lib/node_modules/@anthropic-ai/claude-code/cli.js:3839:448
    at zA (file:///Users/user/.nvm/versions/node/v22.17.1/lib/node_modules/@anthropic-ai/claude-code/cli.js:4672:7)
    at file:///Users/user/.nvm/versions/node/v22.17.1/lib/node_modules/@anthropic-ai/claude-code/cli.js:4672:842
    at xA (file:///Users/user/.nvm/versions/node/v22.17.1/lib/node_modules/@anthropic-ai/claude-code/cli.js:4674:570) {
  errno: -2,
  code: 'ENOENT',
  syscall: 'open',
  path: 'n/a'
}

Node.js v22.17.1
MarioGiancini · 8 months ago

Confirming this issue on v2.0.76 (macOS Darwin 24.4.0).

Steps to reproduce:

  1. Run /resume
  2. Press R to rename a conversation
  3. Type new name and press Enter
This error originated either by throwing inside of an async function without a catch block, or by rejecting a p romise which was not handled with .catch(). The promise rejected with the reason:
Error: ENOENT: no such file or directory, open 'n/a'
at openSync (unknown)
at <anonymous> (/$bunfs/root/claude:12:1277)
at sw (/$bunfs/root/claude: 11:8463)
at appendFileSync (/$bunfs/root/claude:12:1200)
at _g_ (/$bunfs/root/claude:1049:3119) at pGR (/$bunfs/root/claude: 1050:78) at pGR (/$bunfs/root/claude:1050:214)
at ‹anonymous> (/$bunfs/root/claude:3795:475) at ‹anonymous> (/$bunfs/root/claude:3795:527)
at WT (/$bunfs/root/claude:

The conversation itself is fine, but the rename fails.

greghughespdx · 8 months ago

Same issue for me, only I observed it when in the /resume function, and choosing R to rename, then providing the name.

faizan-ali · 7 months ago

Confirming this is happening to me today.

I needed to rename for the first time to mark sessions I've reviewed and ran into this.

Environment Info

Platform: darwin
Terminal: iTerm.app
Version: 2.0.76
Feedback ID: f5902e3a-1050-41ec-8801-06d2f55e96a1

I will buy you dinner in SF if you fix this 🙏🏽

faizan-ali · 7 months ago

This seems to be resolved in the latest version!

github-actions[bot] · 6 months ago

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

bcherny collaborator · 10 days ago

Thanks for the detailed report — the stack trace made this one traceable.

I investigated on Linux against the current release (2.1.233). I couldn't drive the full interactive rename flow in my test environment, but I compared the released builds directly: in 2.0.73 (your version), sessions listed via certain paths (e.g. branched/forked conversations) could carry a placeholder file path internally, and renaming one of those wrote the new title to the literal path n/a — producing exactly the ENOENT: no such file or directory, open 'n/a' error you saw.

This was fixed in a recent release: rename now resolves the session's real transcript path, and the placeholder no longer exists in 2.1.233 at all. See the changelog for what's shipped since 2.0.73: https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md

Please update to the latest version (claude update or reinstall) — renames should persist correctly. Closing — reply to reopen if you still hit this on a current build.

🤖 Generated with Claude Code