A Claude AI agent that could fill every text field on a web form stopped dead at the final step when it tried to attach three images, exposing an undocumented limitation in the Desktop App’s file-upload handling. The failure matters because it turns a seemingly complete end-to-end automation into a manual hand-off, forcing developers to rethink how they build AI-driven workflows.

Why the problem shows up now

Claude agents run in three environments: a command-line interface (CLI), a Visual Studio Code extension, or the standalone Desktop App. In the CLI, the agent reads a file from a directory added to the session and uploads it without issue. The Desktop App does not carry over that behavior. Even when the agent writes a file to its own temporary folder, the app rejects the upload, citing an internal definition of “shared” files that never appears in the public docs.

The discrepancy surfaced when a user built an automation that filled a form, clicked “save draft,” and then tried to attach three images. The text fields populated flawlessly, but the upload step returned an error every time.

What developers have tried

  • Added the files to the session folder that the app creates.
  • Used the directory-connect tool that lets the agent see a host folder.
  • Attached the images directly in the chat window.
  • Created a manual upload folder and pointed the form at it.

All of these approaches produced the same rejection error. The browser window that displays the file-picker dialog runs in read-only mode for desktop automation. The agent can see the dialog but cannot click inside it or type a path, so UI-automation tricks fail.

A fragile “backdoor”

The only method that succeeded used the Windows clipboard:

  1. A PowerShell script copies the target file onto the clipboard.
  2. The agent sends a Ctrl + V keystroke.
  3. The browser receives the paste event and uploads the file.

This hack works, but it wipes the user’s clipboard, is limited to Windows, and could break with any update to the Desktop App. It is not a sustainable solution for production pipelines.

What the limitation really means

The core issue is not a software bug; it is an undocumented surface that treats file permissions as a property of the host application rather than a simple file-system flag. In the CLI, the agent inherits the process’s read access, so any file the session can see can be uploaded. In the Desktop App, the runtime isolates the agent’s file-system view, allowing only files that meet the hidden “shared” criteria.

Because the restriction is baked into the Desktop App’s architecture, workarounds that rely on UI manipulation or temporary folders have not succeeded.

Reliable paths forward

If a workflow requires file uploads, developers have three dependable options:

  • Run the agent from the CLI. This environment respects the session’s file-system permissions and uploads without extra steps.
  • Use the VS Code extension. The extension mirrors the CLI’s permission model, letting agents read and upload files that the editor can see.
  • Leave the upload step to a human. A quick two-minute manual action beats hours spent engineering a brittle workaround.

Choosing the first two options runs the automation outside the Desktop App.

Bottom line

File-upload capability in Claude AI agents is not universal across runtimes; it hinges on how the agent is launched. For dependable automation, treat the CLI and VS Code extension as the only environments that reliably honor file-system permissions. When using the Desktop App, plan for a manual hand-off or accept a fragile clipboard hack. Ignoring this distinction can turn a smooth end-to-end script into a costly debugging exercise.

Source: https://dev.to/mxhlix/my-agent-filled-in-every-field-on-the-form-it-could-not-attach-the-three-images-23kh