The right checks depend on how the document reaches the AI. This guide separates the two routes and points you to the relevant provider guidance.
How AI tools access files: the short answer
First, work out how the file reaches the tool:
-
Chat attachment. You select a file for a conversation, project or knowledge surface. The provider decides which types, sizes, counts and processing routes are currently supported. Depending on the product and route, acceptance does not mean every part of the file will be available for a particular answer.
-
Workspace access. A coding agent operates within a bounded local or cloud working area. The operational questions are whether the environment can reach the path, whether the sandbox allows a command to act there, whether permissions allow or require approval for the tool or action, and whether network access is available. The files may already be there, and layered controls determine the agent's reach.
These are different access models with different controls and failure modes. A file being reachable in a workspace is not the same as attaching it to a chat. OpenAI, for example, documents separate file, usage, storage and plan limits in its File Uploads FAQ. Meeting the applicable upload limits does not tell you how much of the document will be available to or reflected in a particular answer.
Chat attachment and coding workspace are different access models
Chat products such as ChatGPT, Gemini Apps and Claude.ai each maintain their own upload surfaces with distinct limits and processing behaviour. OpenAI documents ChatGPT conversation uploads as an attachment workflow governed by file, usage, storage and plan limits (OpenAI File Uploads FAQ). Google describes Gemini Apps as accepting files in prompts with type, count, size, duration, context and rolling limits that apply to the named surface, not the Gemini API (Google Gemini Apps help). Anthropic documents Claude.ai chat and Project attachment behaviour as distinct from Claude Code and the Anthropic Files API (Anthropic Claude help).
Coding agents operate under a different model. OpenAI defines the Codex sandbox as a technical filesystem and network boundary applied to local command execution, separate from approval behaviour that determines when the agent asks before acting (OpenAI Codex Sandboxing docs). Anthropic documents that Claude Code workspace access is governed by tool permissions and working-directory rules rather than consumer-chat upload caps (Anthropic Claude Code Permissions docs).
The practical difference is scope. With an attachment, you select particular files for a named chat surface. In a workspace, many files may already sit within the agent's reachable scope because a person, repository checkout or build process placed them there. Files can also have different read and write permissions.
The processing job is separate from that scope. A chat surface may extract text, interpret visuals or omit content depending on the product, plan and route. A coding agent may read, summarise or modify reachable files using its available tools. Sandbox and permission settings govern reach and actions; they do not determine the task the model performs.
Attaching a file does not by itself alter the source file. A coding agent with write permission may change workspace files, so use version control or another approved recovery method before allowing edits.
Choose the right file-handling guide
Use the task you are trying to complete to find the relevant guide.
Find the right file-access guide.
| Your task | What to check | Guide |
|---|---|---|
| Upload a file to ChatGPT | Current format, size, rate and storage limits | Check ChatGPT file-upload limits |
| Fix a failed ChatGPT upload | The exact error, then format, account and browser conditions | Troubleshoot a ChatGPT file upload |
| Ask ChatGPT about a PDF | Whether the route can use the text, images and tables you need | See what ChatGPT can read in a PDF |
| Upload files to Gemini Apps | Current type, count, size and context limits | Check Gemini Apps file-upload limits |
| Upload files to Claude.ai | Chat versus Project limits, type and PDF handling | Check Claude.ai file-upload limits |
| Let Codex work with project files | Sandbox reach, writable roots and permissions | Understand the Codex sandbox and configure Codex permissions |
| Let Claude Code work with project files | Bash isolation, working directories and permission rules | Understand the Claude Code sandbox and configure Claude Code permissions |
Google's Gemini Apps file-upload guidance and Anthropic's Claude.ai file-upload guidance provide the current attachment details for those surfaces. Limits and availability can change.
Limits, context capacity and permissions answer different questions
A file-size or file-count limit sets one condition an upload must meet. Staying within it does not guarantee acceptance or show how much of the content will be available for, or reflected in, a particular answer. Context or retrieval capacity affects which parts of accepted content may be available for that answer. Exact behaviour depends on the product and attachment route, so verify the output against the source when completeness matters.
Rolling rate and storage limits govern different parts of the attachment workflow. Permission rules govern whether an agent can reach or act on a path. A sandbox sets a boundary around what commands can do in the execution environment. None of these controls assesses whether the document should enter the intended AI workflow.
When you encounter a limit, an error or a permission prompt, identify which layer it belongs to before deciding what to do. Confusing a storage cap with a per-file size limit, or a sandbox boundary with a document-safety check, leads to the wrong fix.
What to decide before giving an AI tool a document
Before you attach a file to a chat or place it in an agent-accessible workspace, consider the following questions. They are independent of the provider's technical limits and belong to you, your organisation and the specific task:
-
Do you have organisational permission to use this document with AI? Provider limits do not answer this question. A file can be within every technical cap and still be confidential, restricted or inappropriate for the intended use.
-
Is the document minimised? Share only what the task needs. This avoids unnecessary disclosure and gives the model less irrelevant material to work through.
-
Do you know the exact version? A changed document is a new version with different content. If you checked a document before a previous AI use and then edit it, the new version requires its own assessment.
-
Have you considered whether the document contains instruction-like content or other signals that may affect how an AI processes it? This is a separate question from whether the file will upload successfully or whether the agent can reach the path.
-
Do you understand the documented processing route? An accepted file may not make every element usable for a particular answer. Check the current provider guidance and verify the output when completeness matters.
Check the exact version before intended AI use
Outside documents become AI context through chat attachments, knowledge bases and agent workspaces. .mdSiren provides a document security checkpoint for those workflows: check incoming versions for supported prompt-injection and document-borne risks, get an Approved, Needs review or Quarantine decision, and keep the current eligible Approved copy ready for retrieval and reuse.
Every replacement needs its own check. Once a replacement is accepted, .mdSiren stops supplying the earlier copy—even while the new one is pending or held. Pro API access brings the same document submission, status and eligible Approved retrieval rules to authorised agents and workflows.
See how the document workflow works, or Coming soon. Each decision is limited to the reported checks and coverage; it is not a universal safety guarantee. Access permissions and sandboxing still govern what happens after a file enters your system.
Frequently asked questions
Is giving an AI access to a file the same as uploading it?
No. Uploading is a deliberate attachment action in a chat product where you select a file and submit it. In the coding-agent route covered here, access means the file sits within a workspace the agent may be able to reach, subject to sandbox and permission controls. The two routes have different limits, controls and failure modes.
Do coding agents upload an entire workspace?
Not necessarily. Workspace access is not the same as attaching every file to one chat. The execution and data-handling model varies by product, surface and configuration, so this guide does not make a universal claim about what is transmitted.
Does an accepted upload mean the AI read the whole file?
No. Acceptance shows only that the provider accepted the file at that point. Whether every page, visual, embedded object or detail was available depends on the product, plan, attachment route and input type. A successful upload is not proof of complete analysis or comprehension.
Are file permissions a document-security check?
No. Permissions and sandbox rules control reach and actions. They do not assess the document's content or decide whether that exact version should enter the AI workflow. Being readable does not establish that a file has been reviewed for prompt-injection signals or task appropriateness.
Should a changed file be checked again?
Yes. A changed document is a new version. It must not inherit an earlier result. If you assessed a document before a previous AI use and then edit it, the new version requires its own check before reuse. This applies regardless of whether the change is a single character or a full rewrite.
