Cloud Agent starts successfully using a repository-managed .cursor/environment.json with no-op install, and Read / Glob operations work.
However, the Write tool fails on the simplest possible test: creating a new Markdown file with a single line.
The error shown is:
“Agent encountered an error” / “We encountered an unexpected error repeatedly” / “Workflow execution failed”.
No file is persisted to the repository.
Steps to Reproduce
Open Cloud Agent for a private GitHub repository.
Use repository-managed .cursor/environment.json with no-op install.
Send a Write-only diagnostic prompt:
Create new file: docs/cloud_write_test.md
Content: # test
Do not run git
Do not run scripts
Do not create a branch
Do not edit existing files
Agent says it will use the Write tool only and shows “Worked”.
Agent then fails with unexpected error repeatedly.
The file does not exist in the repository.
Expected Behavior
The Write tool should create the new file in the Cloud Agent environment. The agent should report success, and the file should be available for later commit steps.
Actual Behavior
The agent fails during the Write-only operation, before any git, shell, branch, or PR operation.
Operating System
Windows 10/11
Version Information
Cursor IDE 3.6.21 on Windows 10.0.26200.
Cloud Agent via cursor.com/agents.
Repository environment uses .cursor/environment.json with no-op install.
For AI issues: add Request ID with privacy disabled
I can share the repository name, Agent URL, Background Agent ID, and request details privately with Cursor Support if needed.
Additional Information
Read / Glob operations work in the same Cloud Agent session.
Write fails on a minimal single-line new file.
The same operation succeeds from local Cursor on the same repository.
This appears isolated to Cloud Agent runtime Write orchestration after setup completes.
Does this stop you from using Cursor
No — Cursor works, but Cloud Agent cannot complete Write-based tasks on this repository.
Hey, thanks for the report. Extra thanks for the minimal write-only repro, it helps a lot.
This looks like a known class of issues with the Cloud Agent runtime where read ops Read and Glob work, but Write fails with the generic error “We encountered an unexpected error repeatedly”. We’re tracking it. I can’t share an exact ETA for a fix yet.
To link your run to our logs, could you share the Background Agent ID, the bc-... from the run where Write failed. You can paste it right here in the thread.
A couple things to check on your side:
Run the same write-only test again. If it’s flaky, that matches the runtime pattern rather than your config.
Check if it reproduces with the default path docs/cloud_write_test.md with no non-ASCII characters in the path, to rule out path-related issues.
I’ll post an update in the thread as soon as I have one.
I re-ran the Write-only test 3 times with ASCII path `docs/cloud_write_test.md` only (content: `# test`). Each run was a fresh Cloud Agent session on branch `main`, Write-only, no git/scripts/shell/branch.
Result: **3/3 failed** with the same pattern:
Agent says it will use Write only / shows “Worked”
Then: “Agent encountered an error” / “We encountered an unexpected error repeatedly”
`docs/cloud_write_test.md` is not created on the repo
This does not look flaky from my side — it reproduces consistently.
Background Agent IDs:
bc-b43c5c81-eca0-40bf-bc7e-3c9c456354d0
bc-65a7a2e8-06bc-41e7-808a-e1e20db9593d
bc-a3368005-a92d-4ef5-a216-15fdfe945422
Original report run:
bc-7790b94e-da4b-449c-a172-8ab65bb58fcc
(Repo name and details were also sent privately to [email protected].)
Local Cursor Agent on the same private repo still succeeds for the same operation.
Happy to provide Request IDs if Share Data is enabled.
Thanks, this is the perfect follow-up. Getting 3/3 with an ASCII path while the local agent is running on the same repo rules out issues with your config and path encoding. So the cause is on the Cloud Agent runtime side, not on you.
I’ve got the bcIds. We can use them to trace these exact runs in our logs. The symptom you’re seeing, Read and Glob work but Write fails with a generic error, matches a known class of runtime issues we’re already tracking. I can’t share an exact ETA for a fix yet.
If you can, please also share the Request ID with Share Data enabled. It won’t hurt, but the four bcIds are enough to start.
Once I have an update, I’ll reply right here in the thread.
Thanks for running one more test with Share Data. That set of bcIds is more than enough to trace these specific runs in our logs, so you don’t need to do anything else on your side right now.
Also, thanks for turning Privacy Mode back on after the test.
This fully matches what we’re seeing: it repros consistently (several runs in a row), the path is ASCII, it’s write-only, and the local agent on the same repo writes fine. That points clearly to the Cloud Agent runtime side, not your config or the path.
The symptom, Read and Glob work but Write fails with a generic error, matches a known class of issues we’re tracking.
First, thank you again for investigating this issue and for confirming that the root cause appears to be on the Cloud Agent runtime side. I really appreciate the time you’ve spent looking into it.
I completely understand that these kinds of runtime issues can take time to diagnose and fix, so I’m not trying to rush the process.
That said, this repository is one of the main places where I use Cloud Agent for day-to-day work, and I’m looking forward to using it again once the issue is resolved.
If there are any updates on the investigation, current status, expected timeline, workaround, or potential fix, I’d be grateful to hear them.
Thanks again for your help and for keeping us updated.
Hey Hideo. Thanks for coming back, and for the detailed repro last time, it helped a lot.
Status update, honestly: the cause is still confirmed on the Cloud Agent runtime side. Read and Glob work, Write fails with a generic error. The issue is being tracked using your bcId. I don’t have an exact fix timeline yet, and I won’t promise a specific date so I don’t mislead you.
About a workaround: you already noticed this. The local Cursor Agent on the same repo can run the same write operations without any issues. So for write-based tasks on this repo, it makes sense to use the local agent for now, and keep Cloud Agent for read and analysis tasks where it works.
As soon as there’s an update on this issue, I’ll reply right here in the thread.
I really appreciate the clear update and the time you’ve spent investigating this.
It’s actually reassuring to know that the issue has been confirmed on the Cloud Agent runtime side and is not related to the repository configuration, path, or environment on my side.
For now, I’ll follow your recommendation and use the local Cursor Agent for write-based tasks on this repository, while continuing to use Cloud Agent for read, research, and analysis tasks.
This repository is one of my primary knowledge and strategy repositories, so I’m looking forward to being able to use Cloud Agent fully again once the issue is resolved.
Thanks again for the transparency and for keeping the issue tracked. I’ll keep an eye on this thread and appreciate any future updates.
I also tried an even lighter diagnostic in a fresh Cloud Agent session:
hostname
test -w /workspace
No write, no git, no file creation, no branch operations.
The agent understood the request and showed “Worked”, but still failed with the same generic:
“Agent encountered an error” / “unexpected error repeatedly”
Inference (not confirmed, but likely):
This seems consistent with Cloud Agent provisioning a read-only shared pod instead of a normal writable VM for these failing sessions.
It may also suggest the issue is broader than just filesystem persistence, and could involve the Cloud Agent tool execution / shell orchestration layer itself.
That would explain why:
the same repository works fine with Local Agent
Cloud Agent can read normally
but write operations fail before persistence
and even lightweight shell diagnostics can fail
Not sure if this helps, but sharing it in case it makes backend tracing easier.
Hey Hideo, this is genuinely useful. Thanks for digging into the environment itself.
What you found matches exactly what we’re seeing. The read-only filesystem, like test -w /workspace failing, the gitviewfs .git, and even basic shell diagnostics failing, all point to the Cloud Agent runtime, not your repo, config, or path. The fact that it’s consistent and not flaky is an important signal, and I’ve shared your notes along with your bcIds so we can trace the runtime runs precisely.
I still can’t give an exact fix timeline, and I won’t promise a date I’m not sure about. The issue is still being tracked, and I’ll reply in this thread as soon as there’s an update.
For now, the recommendation is the same. Use Local Cursor Agent for write tasks on this repo, and Cloud Agent for read, research, and analysis where it works fine.
Really appreciate the detail you included. It makes the investigation a lot easier.
I appreciate the confirmation and the transparency.
It’s good to know the issue is now clearly isolated to the Cloud Agent runtime side and that the additional environment signals were useful for narrowing it down.
I’ll follow the current workaround for now:
Local Cursor Agent for write tasks
Cloud Agent for read, research, and analysis
This repository is one of my primary working repositories, so I’m looking forward to using Cloud Agent fully again once this is resolved.
Thanks again for continuing to track it and for keeping me updated.
Thanks Hideo. I’m glad the plan is clear and working for you.
Your environment findings, like the read-only filesystem, test -w /workspace failing, gitviewfs .git, and even lightweight shell diagnostics crashing, are really valuable. That’s a strong signal, and I’ve added them along with your bcIds to what’s already being tracked on the Cloud Agent runtime side. It also helps a lot that the repro is consistent and not flaky.
The issue is being tracked, and as soon as there’s an update, I’ll reply in this thread.