[BUG] `/export` silently ignores destination argument when filename has extension
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 contains a file extension (e.g., test.txt, test.md), the /export command uses only the first argument as the filename and silently ignores any additional arguments. The file is always written to the current working directory with no warning that the destination was discarded. Custom extensions like .md are also overridden — the output is always .txt.
What Should Happen?
If a destination argument is supported, it should be honored. If it is not supported, the command should warn the user or document single-argument usage. Custom file extensions should be preserved.
Error Messages/Logs
> /export test.txt /Users/rich/Desktop/
Conversation exported to: /Users/rps/Desktop/old-github/claude-code/test.txt
> /export test.md /Users/rich/Desktop/
Conversation exported to: /Users/rps/Desktop/old-github/claude-code/test.txt
> /export test.md ~/Desktop
Conversation exported to: /Users/rps/Desktop/old-github/claude-code/test.txt
No error is shown — the destination is silently ignored in all cases and .md is overridden to .txt.
Steps to Reproduce
- Open Claude Code in any project directory
- Run
/export test.txt /Users/<you>/Desktop/ - Observe the file is created in cwd, not the specified destination
- Run
/export test.md /Users/<you>/Desktop/ - Observe the file is created as test.txt in cwd — both destination and .md extension ignored
Claude Model
Opus
Is this a regression?
Yes, this worked in a previous version
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 3 comments on GitHub. Read the full discussion on GitHub ↗