I’m posting this because I spent several hours investigating what happened, and after looking for a way to provide detailed feedback to the Codex team, I couldn’t find an obvious channel for it.
This is not intended as a complaint about model quality. I never got far enough to meaningfully evaluate Codex’s coding capabilities.
Instead, this is feedback about onboarding, filesystem scope, user trust, and the interaction between Codex and OneDrive Files-On-Demand.
Context
Environment:
- Windows
- VS Code
- ChatGPT Business
- OneDrive Business
- OneDrive Files-On-Demand enabled
My project was located at:
C:\Users\[user]\[OneDrive Business]\Python Scripts
This is my personal area within our business OneDrive account, not a shared team library.
A few days before trying Codex, I had intentionally cleaned up my machine and returned a large number of files to cloud-only status to save local disk space.
What I Expected
My expectation was simple:
- Install Codex in VS Code.
- Allow it access to my Python project.
- Use it to help with development.
I assumed the sandbox setup process was a normal installation step required for the extension to function.
I did not expect anything outside the project I had opened to be touched.
What Happened
During setup, Codex downloaded and installed:
codex-windows-sandbox-setup.exe
Shortly afterwards, OneDrive started downloading cloud-only files.
At first I assumed it was related to my project.
Then I started noticing files such as:
- Hotel receipts
- Travel invoices
- Uber receipts
- Costa Coffee receipts
- Miscellaneous PDFs and images
These files were not part of my Python project.
They existed elsewhere in my OneDrive.
Many had been intentionally converted back to cloud-only status only a few days earlier.
Seeing them suddenly reappear as downloads immediately raised concerns.
Why This Was Concerning
The issue was not disk space.
The issue was not bandwidth.
The issue was uncertainty.
I couldn’t determine:
- What Codex was accessing
- Why it was accessing it
- Whether it was expected behaviour
- Whether it would continue
From my perspective, I had opened a Python project.
Yet OneDrive appeared to be downloading unrelated files from elsewhere within my OneDrive area.
Whether there is a perfectly reasonable technical explanation for this is almost secondary to the user experience.
The observable behaviour was:
- Install Codex.
- Enable sandbox.
- OneDrive starts downloading unrelated files.
That’s a difficult first impression.
Investigation
I spent a fair amount of time trying to understand what was happening.
I:
- Checked OneDrive activity
- Reviewed Task Manager
- Looked for Codex processes
- Inspected Codex configuration
- Investigated sandbox settings
- Reviewed workspace scope
Eventually I found the Codex configuration:
[windows]
sandbox = "elevated"
However, I still couldn’t find a clear explanation that answered the question I cared about:
What exactly can Codex see and access, and how does that interact with OneDrive Files-On-Demand?
The Trust Problem
This is the main reason I’m posting.
I don’t think the biggest issue is whether Codex technically behaved correctly.
The bigger issue is that I lost confidence that I understood what it was doing.
For developer tools, trust matters a lot.
When a tool appears to interact with files outside the area you expected, users immediately start wondering:
- What is being scanned?
- What is being indexed?
- What is being accessed?
- What are the actual boundaries?
I never found answers that made me comfortable enough to continue using it.
As a result, I removed the extension.
Suggestions
A few ideas that I think would significantly improve the onboarding experience:
1. Detect OneDrive Files-On-Demand
If the workspace is inside OneDrive and Files-On-Demand is enabled, display a warning explaining that file access may cause cloud-only files to be downloaded locally.
2. Make Scope Explicit
Show users exactly what Codex can access.
For example:
Current scope:
C:\Users\[user]\[OneDrive Business]\Python Scripts
or
Filesystem scope:
C:\Users\[user]
Being explicit would help build trust.
3. Show Scanning Activity
If Codex is indexing, discovering files, or gathering context, surface that activity.
Something like:
Scanning 143 files in workspace…
would be much more reassuring than silent background activity.
4. Offer a Strict Workspace-Only Mode
Many users would likely prefer:
Only access files inside the currently opened workspace.
even if it limits functionality.
Secondary Feedback: I Couldn’t Find a Way to Submit This
The other surprising part of this experience was what happened afterwards.
I spent time:
- Investigating the issue
- Gathering screenshots
- Working through possible causes
- Writing detailed feedback
Then discovered there wasn’t an obvious way to submit that feedback directly to the Codex team.
That feels like a missed opportunity.
AI systems are increasingly capable of helping users create high-quality bug reports and product feedback.
Yet there doesn’t appear to be a straightforward workflow for:
“Submit this feedback to the product team.”
The result is that motivated users end up with useful feedback and no clear destination for it.
Final Thoughts
I want to emphasize that this post is not intended as an attack on Codex.
I was actually excited to try it.
The reason I uninstalled it wasn’t because it generated bad code.
It was because I lost confidence that I understood its filesystem boundaries and how it interacted with OneDrive.
If there is a clear technical explanation for what happened, I’d genuinely be interested in hearing it.
And if anyone from the Codex team reads this, I’d strongly encourage improvements around:
- Scope visibility
- OneDrive awareness
- Onboarding clarity
- Feedback submission workflows
Because those were ultimately the things that caused me to abandon the product before I ever really got to use it.