[BUG] `/export` concatenates multiple arguments into a single filename when no extension present
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
When the first argument has no file extension, all arguments (including paths intended as destinations) are concatenated into a single filename string with spaces preserved, then .txt is appended. This creates invalid file paths that fail with ENOENT.
What Should Happen?
Arguments should be parsed consistently. Either support a <name> <destination> syntax and parse correctly, or reject multiple arguments with a clear error message.
Error Messages/Logs
> /export test ~/Desktop
Failed to export conversation: ENOENT: no such file or directory, open '/Users/rps/Desktop/old-github/claude-code/test ~/Desktop.txt'
> /export test /Users/rps/Desktop
Failed to export conversation: ENOENT: no such file or directory, open '/Users/rps/Desktop/old-github/claude-code/test /Users/rps/Desktop.txt'
> /export test /Users/rps/Desktop/test.txt
Failed to export conversation: ENOENT: no such file or directory, open '/Users/rps/Desktop/old-github/claude-code/test /Users/rps/Desktop/test.txt'
Steps to Reproduce
- Open Claude Code in any project directory
- Run
/export test ~/Desktop - Observe the error shows the entire string test ~/Desktop.txt used as one filename
- Run
/export test /Users/<you>/Desktop - Observe the same concatenation behavior
Claude Model
Opus
Is this a regression?
I don't know.
Last Working Version
_No response_
Claude Code Version
2.1.92 (Claude Code)
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
The /export command appears to support relative paths with extensions (e.g., /export ../../test.txt correctly resolves the path), but this is undocumented. /help export provides no information about supported arguments, path syntax, or expected behavior.
The presence or absence of a file extension in the first argument fundamentally changes how the command parses input:
- With extension: only first arg used as filename, relative paths resolve, destination arg silently ignored
- Without extension: all args concatenated as filename, relative paths mangled
This suggests the path resolution logic exists but is gated behind extension detection, and the no-extension code path has a different (broken) implementation.
Tested on macOS with both Opus 4.5 and Opus 4.6 — identical behavior.
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗