Skip to content

Copilot-cli changes all files it touches to have CRLF line endings even when the original file has LF line endings #1148

New issue
New issue
Closed
Bug
Closed
Copilot-cli changes all files it touches to have CRLF line endings even when the original file has LF line endings#1148
Bug
Labels
area:platform-windowsWindows-specific: PowerShell, cmd, Git Bash, WSL, Windows Terminalarea:toolsBuilt-in tools: file editing, shell, search, LSP, git, and tool call behavior

Description

@BillyONeal
BillyONeal
opened on Jan 27, 2026

Describe the bug

  1. Have any file with LF line endings.
  2. Do any prompt that gets copilot to edit the file
  3. The file has been changed to CRLF line endings

Affected version

0.0.395 Commit: 4b4fe6e

Steps to reproduce the behavior

PS C:\Dev\vcpkg-tool> copilot
╭──────────────────────────────────────────────────────────────────────────────────────────────────╮
│  ╭─╮╭─╮                                                                                          │
│  ╰─╯╰─╯  GitHub Copilot v0.0.395                                                                 │
│  █ ▘▝ █  Describe a task to get started. │ Copilot uses AI, so always check for mistakes.        │
│   ▔▔▔▔                                                                                           │
│  Pick a model with /model. Delegate changes with an AI-generated PR using /delegate.             │
│  Enter ? to see all commands.                                                                    │
╰──────────────────────────────────────────────────────────────────────────────────────────────────╯

 ❯ In @src\vcpkg.cpp under `#include <vcpkg/cgroup-parser.h>` add a comment describing why this header is included.

 ✓ Read src\vcpkg.cpp lines 1-160
   └ 164 lines read

 ✓ Edit src\vcpkg.cpp

 ● Comment added above cgroup-parser include explaining its use for container detection.

 Total usage est:        1 Premium request
 API time spent:         7s
 Total session time:     51s
 Total code changes:     +0 -0
 Breakdown by AI model:
  gpt-5.1-codex-max       40.9k in, 384 out, 19.3k cached (Est. 1 Premium request)

 Resume this session with copilot --resume=2e8f3876-d7d5-430d-86f6-2b2ef57e1717

Now src\vcpkg.cpp got changed to CRLF line endings.

My .gitattributes is:

cat .\.gitattributes
# Don't allow people to merge changes to these generated files, because the result
# may be invalid.  You need to run "rush update" again.
ce/pnpm-lock.yaml               merge=binary
ce/shrinkwrap.yaml              merge=binary
ce/npm-shrinkwrap.json          merge=binary


# Disable line ending smudges entirely.
* -text

# Rush's JSON config files use JavaScript-style code comments.  The rule below prevents pedantic
# syntax highlighters such as GitHub's from highlighting these comments as errors.  Your text editor
# may also require a special configuration to allow comments in JSON.
#
# For more information, see this issue: https://github.com/Microsoft/web-build-tools/issues/1088
#
*.json                       linguist-language=JSON-with-Comments
*.png               binary
*.gif               binary
*.mp4               binary

Expected behavior

The file that started with LF line endings keeps LF line endings.

Additional context

No response

Activity

  1. BillyONeal
    added
    triage
    on Jan 27, 2026
  2. BillyONeal
    added the
    Bug
    issue type on Jan 27, 2026

  3. BillyONeal commented on Jan 27, 2026

    @BillyONeal
    BillyONeal
    on Jan 27, 2026
    Author

    When I tested this a few weeks ago I could have swore I tried different models and got the same behavior with all of them but this MAY be gpt-5.1-codex-max's fault.

  4. dscho commented on Mar 15, 2026

    @dscho
    dscho
    on Mar 15, 2026

    This happens to me now, too, with Claude Opus 4.6. It's definitely a new thing.

  5. IanGraingerGMSL commented on Mar 24, 2026

    @IanGraingerGMSL
    IanGraingerGMSL
    on Mar 24, 2026

    I've seen Copilot creating files with CRLF when everything else is LF and my .gitattributes has: * text eol=lf

  6. BillyONeal commented on Apr 1, 2026

    @BillyONeal
    BillyONeal
    on Apr 1, 2026
    Author

    Is it possible that somewhere under the covers this is being piped through PowerShell commands? PowerShell's > operator does this rewriting.

  7. examon
    added
    area:toolsBuilt-in tools: file editing, shell, search, LSP, git, and tool call behavior
    area:platform-windowsWindows-specific: PowerShell, cmd, Git Bash, WSL, Windows Terminal
    and removed
    triage
    on Apr 16, 2026

  8. angeldeejay commented on Apr 24, 2026

    @angeldeejay
    angeldeejay
    on Apr 24, 2026

    I'm at the same place as you. I've solved the problem by installing an external tool and wiring it to the context, telling the agent to use it after saving files. If it can be useful to you, feel free to use it /eol-converter-enhanced

  9. sandynz commented on May 11, 2026

    @sandynz
    sandynz
    on May 11, 2026

    Still reproducible in GitHub Copilot CLI v1.0.44 (2026-05-11) and v1.0.49 (2026-05-19) on Windows 11 / PowerShell 7.

    Evidence (v1.0.44, Windows 11 / PowerShell 7, 2026-05-11):

    A test file was created via the create tool with LF-only content (5 lines).
    Raw byte inspection immediately after write:

    $b = [IO.File]::ReadAllBytes("_plan_/_test_encoding.md")
# CR (0x0D) found at positions: 20, 22, 30, 38, 46
# File size: 48 bytes (LF-only would be 44 bytes)
# First 40 bytes:
# 23 20 45 6E 63 6F 64 69 6E 67 20 74 65 73 74 20 66 69 6C 65
# 0D 0A 0D 0A 4C 69 6E 65 20 31 0D 0A 4C 69 6E 65 20 32 0D 0A

    Every line ending is 0D 0A (CRLF). The .gitattributes file in the repo root
    specifies * text=auto eol=lf, which is ignored by the tool's write path.

    Evidence (v1.0.49, Windows 11 / PowerShell 7, 2026-05-19):

    Independently reproduced with a 3-line file via create tool:

    CRLF(0x0D0A) = 3
LF-only(0x0A) = 0
BOM            = false
total_bytes    = 39

    A pre-commit hook (scripts/hooks/pre_commit_normalize.py) fires on every session,
    confirming the injected CRLF is a consistent, repeatable behaviour.

    Correction to cascading effect: An earlier report noted that CRLF files could break
    subsequent edit calls when old_str spans multiple lines. Further testing (v1.0.49,
    2026-05-19) showed that the edit tool does normalize line endings during old_str
    matching     — LF old_str successfully matches CRLF file content. The cascade risk is
    therefore not from old_str matching failures, but from downstream Python/script
    processing that re-introduces CRLF when not using newline='\n'.

  10. BillyONeal
    added a commit that references this issue on May 23, 2026

    Patch Tuesday for May 2026 (#51854)

    aa40add

  11. PacePioneer commented on Sep 15, 2026

    @PacePioneer
    PacePioneer
    on Sep 15, 2026

    This happens to me almost daily, and the agent uses more tokens to solve it. I'm surprised this is still an issue

  12. examon
    closed this as completedon Nov 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:platform-windowsWindows-specific: PowerShell, cmd, Git Bash, WSL, Windows Terminalarea:toolsBuilt-in tools: file editing, shell, search, LSP, git, and tool call behavior

    Type

    Bug

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions