[BUG] `/export` mangles filename when relative path has no 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?
Relative paths with ../ work correctly when the filename has an extension, but without an extension the path components corrupt the filename. The actual filename is dropped and only ..txt remains.
What Should Happen?
Relative paths should resolve correctly regardless of whether a file extension is provided. /export ../../test should produce test.txt in the resolved directory.
Error Messages/Logs
> /export ../../test
Conversation exported to: /Users/rps/Desktop/old-github/..txt
> /export ../../
Conversation exported to: /Users/rps/Desktop/old-github/..txt
> /export ../../test.md
Conversation exported to: /Users/rps/Desktop/test.txt (works, but .md overridden)
Steps to Reproduce
- Open Claude Code in a nested project directory (e.g., ~/Desktop/old-github/claude-code)
- Run
/export ../../test - Observe the output path is
<parent>/..txtand the filename "test" is lost - Run
/export ../../test.md - Observe this resolves correctly (but .md is overridden to .txt)
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 ↗