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
- Open Claude Code CLI
- Have an existing thread/conversation
- 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
9 Comments
same issue
same here
Same here, still happening on v2.0.76 in VSCode terminal while trying to rename session name.
Confirming this issue on v2.0.76 (macOS Darwin 24.4.0).
Steps to reproduce:
The conversation itself is fine, but the rename fails.
Same issue for me, only I observed it when in the /resume function, and choosing R to rename, then providing the name.
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 🙏🏽
This seems to be resolved in the latest version!
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.
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 theENOENT: 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 updateor reinstall) — renames should persist correctly. Closing — reply to reopen if you still hit this on a current build.🤖 Generated with Claude Code