Failure to write to file

[amkza]

Describe the bug

Consistent failure to write/edit when telling it to create a plan but don't make any code changes yet.

Affected version

GitHub Copilot CLI 1.0.39

Steps to reproduce the behavior

I run copilot cli.
I switch to 'autopilot'
I select my model and I enable all permissions.

I have a prompt ready, this prompt will do some research on a feature I want to implement.
The prompt is a research and planning prompt.
The aim is to create a detailed plan.md file in my project folder.

It does the research it creates the plan, but it cannot save the plan.
It tries to write to various different files, locations (session-state, project location), etc
All writes fail

I see red text how it is failing to make any writes.

This used to work a couple of versions back (1.0.24 etc)

If I run the same prompt again in a new session and I change this text:

"This is only a planning task. Do not implement the code yet."

to

"This is a planning task."

Then it works 100% and it creates the plan.md without a single issue.

It is as if the instruction to not make code changes suddenly restricts it from making any file edits.

This use to work fine.

I have a personal and a business github copilot account and I have had the same happen on both accounts on different machines, both are v1.0.39

Expected behavior

No response

Additional context

No response

[amkza]

I ran into it again.

I got angry with Copilot and suddenly it could write to the file without issues 😄

I asked it to tell me what is wrong - but don't know if this helps or if it is hallucinating.

I'm running on WSL in Windows 11.

● What was wrong: it was not a real Linux filesystem permission problem. It was an intermittent tool/runtime write-authorization failure.

Exact evidence from this session:

--- Test Execution Log ---

• Operation: apply_patch add plan.md

  • Target: /home/amkza/.copilot/session-state/.../plan.md
  • Result: Failed with Permission denied and could not request permission from user

• Operation: apply_patch add via relative ../../../.copilot/.../plan.md

  • Target: same file
  • Result: Failed with the same message

• Operation: bash here-doc redirect > /home/.../plan.md

  • Target: same file
  • Result: Failed once with Permission denied and could not request permission from user

• Operation: bash cd ... && touch plan.md

  • Target: same directory
  • Result: Succeeded

• Operation: bash Python Path('plan.md').write_text(...) after cd

  • Target: same directory
  • Result: Succeeded

• Operation: Reproduction later: absolute shell redirect and absolute Python write

  • Target: same directory
  • Result: Both succeeded

Why that matters: the directory itself was writable the whole time. I verified:

• /home/amkza/.copilot/session-state/48e0deb9-058f-484d-a579-a26253092375 existed
• owner was amkza
• permissions were drwx------
• the process was running as uid=1000(amkza)

So the OS permissions were fine. If this were a real filesystem issue, touch and Python writes would have failed too.

Most likely bug to log:

Copilot CLI/runtime intermittently blocks writes to the session plan path with the message Permission denied and could not request permission from user, even though the agent user owns the directory and can write to it successfully in later commands. The failure appears to
come from the tool/runtime authorization layer rather than the filesystem.

Useful notes for the bug report:

1. The failure affected both apply_patch and some bash write commands.
2. The same path later became writable without any permission change.
3. The error string was tool-generated, not normal shell stderr.
4. The behavior was inconsistent/intermittent, which suggests a runtime path-authorization or approval-routing bug rather than Unix permissions.

Short bug summary you can paste:

Writing plan.md in the Copilot session folder intermittently fails with Permission denied and could not request permission from user, even though the directory is owned by the current user and later writes to the same path succeed. This looks like a Copilot CLI/runtime
write-authorization bug, not a filesystem permission issue.

[CezaryKlus]

I started to have this consistently with messages similar to: not created/overwritten (file write blocked in this environment).