[BUG] Claude Code consistently creates files with Windows line endings on Linux systems
Description: Despite being on Ubuntu Linux and explicitly adding instructions to CLAUDE.md, Claude Code continues to create shell scripts and text files with Windows line endings (CRLF) instead of Unix line endings (LF). This causes "No such file or directory" errors when executing scripts.
Steps to Reproduce:
- Use Claude Code on Linux (Ubuntu 24.04)
- Ask it to create any shell script
- Try to execute the script with ./script.sh
- Get error: "unable to execute ./script.sh: No such file or directory"
Expected Behavior: Files should be created with Unix line endings (\n) on Linux systems
Actual Behavior: Files are created with Windows line endings (\r\n), requiring manual conversion with sed -i 's/\r$//'
Environment:
- OS: Ubuntu 24.04.2 LTS
- Kernel: 6.11.0-26-generic
- Claude Code version: [your version]
Impact:
- Breaks workflow repeatedly
- Requires manual intervention for every script
- Even after adding explicit instructions to CLAUDE.md, the issue persists
Suggested Fix: Claude Code should detect the OS and use appropriate line endings automatically, or at minimum respect the CLAUDE.md instructions.
Claude attempts to find some files in the repo then looks at the line endings for those files. Is it possible that your repo has some files with carriage return newlines?
No, because before every git, it cleans up all of those. my issue is that even when it is checking stuff and writes a script, it always has to come back with an error that "the file has windows endings. let me fix that".
I am surprised for two reasons at least:
- why is this happening in the first place? it is so easy to understand what environment you are running in and make an adjustment from the start.
- this is supposed to be an AI system, why don't you learn from your mistakes and stop repeating them over and over again?
The same thing happens to me when running ssh Linux terminal on Windows. The claude code starting from remote keeps corrupting my bash script by inserting Windows line endings.
Happens here too, very frustrating.
Happens here too. Hot fix needed! Even after adding explicit instructions to CLAUDE.md, the issue persists.
I just asked Claude and he confirmed it:
⏺ Bash(file backend/backup_stuff/*.sh) ⎿ backend/backup_stuff/backup_main.sh: Bourne-Again shell script text executable, ASCII text backend/backup_stuff/filesystem_backup.sh: Bourne-Again shell script text executable, ASCII text backend/backup_stuff/mysql_backup.sh: Bourne-Again shell script text executable, ASCII text … +1 line (ctrl+r to expand)
⏺ Fixed! You're absolutely right - this is a Claude Code bug where I create files with Windows CRLF line endings even on macOS/Unix systems. The files now have proper Unix line endings and should work correctly when you transfer them to your metal server.
This explains why you keep running into this issue - it's happening whenever Claude Code creates shell scripts or other text files that need Unix line endings.
Similar issue here. It does the opposite on Windows Powershell environment. Not only it do LF instead of CRLF on Windows, none of its Powershell or Bash command and run successfully in Powershell environment.
I can't say I see this consistently but from time to time, I have had Claude create files with DOS carriage returns on a Mac. The problem is exacerbated by the fact that Claude doesn't seem to understand what the error message means (python3\r: No such file or directory)
This is pretty bad - I have now dedicated a substantial portion of CLAUDE.md to insisting it stop doing this, and it won't stop doing this.
Hi, thank you for such a good job, I use claude code inside terminal. Same here
The exact opposite happens on Windows, very frustrating.
Same thing happens to me and it makes looking at changes to existing files in our repo a pain. Because of the line ending difference when claude uses the write tool every line is seen as new, so the diff view doesnt work properly.
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.
THe issue is active, do not autoclose