Troubleshooting
Agent Can’t Access My Computer Files?
Why this happens, what your agent can safely access, and the fastest way to share files without getting stuck.
Common trust-break moment: "It’s on my Desktop. Why can’t the agent see it?" In most setups, agents only work inside their assigned workspace unless you explicitly provide files.
The core model: agents are sandboxed by default
- Usually accessible: current workspace files, files you upload, and approved tool outputs.
- Usually not accessible: random local folders, browser tabs, private cloud drives, other app windows.
- By design: this protects your system and prevents accidental data exposure.
Reality check: if a path is outside the agent workspace, treat it as invisible until you copy/upload it into a shared location the agent can read.
2-minute recovery flow
- Ask the agent to print its current working directory.
- List files in that directory to confirm what it can actually see.
- Move/copy your target file into that workspace or upload it directly in chat.
- Ask the agent to quote one line from the file as proof it opened the correct version.
Please do a file visibility check.
1) Print your current workspace path.
2) List files in that directory.
3) Tell me whether you can see: [exact filename].
4) If not visible, tell me exactly where I should place/upload it.
5) After I provide it, quote the first non-empty line as proof.
High-friction mistakes (very common)
- Same filename, wrong folder: `report-final.pdf` exists in multiple places; agent opens the wrong one.
- Old version still present: user updates locally but forgets to re-upload, so agent reads stale content.
- Thread/surface mismatch: file was uploaded in one chat surface, task was run in another.
- Cloud link isn’t public: URL works for you while logged in, but not for the agent.
Avoid this trap: “It should just know where my file is” leads to loops. Always use path proof + quote proof when file identity matters.
Advanced edge cases (when basics look correct)
- iCloud/Desktop sync mismatch (macOS): file appears in Finder but is still cloud-only; copy it into workspace and retry.
- Zipped content not extracted: users upload a `.zip` and expect direct file access to inner docs/images.
- Wrong extension / hidden extension: `notes.txt` vs `notes.txt.md` causes “file not found” confusion.
- Unicode/special characters in filename: smart quotes, emojis, and trailing spaces can break exact path matching.
- Case-sensitive mismatch: `Report-Final.pdf` and `report-final.pdf` may behave differently across environments.
Run this strict file-identity check:
1) Print absolute path + byte size + modified timestamp for: [exact filename].
2) If multiple matches exist, list all absolute paths.
3) Open only the newest match and quote line 1 plus line 5.
4) If file is inside a zip, extract first, then repeat proof.
5) If filename has spaces/special characters, print the exact escaped path used.
When to escalate to #help
- File is definitely in the workspace/uploaded, but agent still reports missing.
- Agent reads a different file than requested despite exact filename/path prompts.
- Cross-surface behavior is inconsistent and reproducible after a fresh session.
Support packet (copy/paste)
File visibility issue report
Exact filename:
Where file currently lives (full path or upload surface):
Agent-reported workspace path:
Agent file-list output captured? (yes/no):
Quote proof from file captured? (yes/no):
Are there files with same name in other folders? (yes/no):
Fresh session retest done? (yes/no):
Still failing after retest? (yes/no):
Bottom line: don’t debug this as “model quality.” Debug it as a visibility problem: correct location, then verify with path-and-quote proof.