[Bug] CLI session context confusion between local and remote systems
Bug Description
Claude Code incorrectly inferred the physical machine it was running on based on the working directory name rather than the actual hostname.
The session's working directory was ~/ai/mini-1 (a folder named after a remote machine for organizational purposes). Claude assumed it was physically running on that remote machine ("Mac mini") and began checking local hardware directly
instead of SSHing to the actual remote host.
The user had to explicitly ask "do you understand what I mean by Mac mini?" at which point Claude ran hostname and discovered it was running on the local machine, not the remote one.
Steps to reproduce:
- Create a working directory named after a remote machine (e.g. ~/ai/remote-machine-name/)
- Ask Claude to perform a task on that remote machine (e.g. "find a drive connected to <remote-machine>")
- Claude runs commands locally instead of SSHing to the remote
Expected behavior: Claude should derive machine identity from hostname, not from the working directory name. Directory names are organizational conventions, not machine identity.
Environment Info
- Platform: darwin
- Terminal: iTerm.app
- Version: 2.1.170
Errors
[]
---
All personal identifiers (hostname, username, IP, Feedback ID) removed. The Feedback ID in particular could tie back to your account, so good call leaving that out.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗