Background
We are developing a PPT generation workspace as an Anna App. Besides generating decks, the app lets the user upload their own reference material into the Workspace, such as an existing deck, a spreadsheet of figures, or a requirements document. An analysis Agent then reads those files with the platform reader tools and produces an internal digest that later stages consume.
The attachment ingestion pipeline is roughly:
user picks file -> anna.upload (negotiate + PUT + confirm) -> HostUploadRef -> commit into Workspace -> Agent reads via sheet_read / doc_read
Following the recommended Anna App approach, we do not transfer these files over local loopback HTTP. The user’s file goes to Anna Host through Host Upload first, and the returned HostUploadRef is what our Executa commits into the Workspace as an uploaded source material.
After building this path, we found that Host Upload rejects every common Office document MIME type during negotiate. Images and PDF are accepted on the exact same code path. This currently prevents users from supplying .xlsx, .docx, .pptx, or .xls files at all.
Current Code Implementation
1. Frontend side: uploading the user’s file through anna.upload
When the user picks an attachment, the App calls the Host Upload client and then hands the resulting reference to our Executa to commit:
const hostUpload = await hostUploadClient.uploadFile(file, {
purpose: "user_artifact",
filename: file.name,
mimeType: file.type || undefined,
metadata: {
source: "ppt-app.uploaded-source",
workspace_dir: workspace.workspace_dir,
},
});
return backend.commitUploadedSourceHostUpload({
workspace_dir: workspace.workspace_dir,
filename: file.name,
mime_type: hostUpload.mime_type,
size_bytes: file.size,
host_upload: hostUpload,
});
The MIME type is not constructed by us. It is file.type as reported by the browser for the file the user selected, which for these formats is the standard registered Office MIME type:
.xlsx application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
.docx application/vnd.openxmlformats-officedocument.wordprocessingml.document
.pptx application/vnd.openxmlformats-officedocument.presentationml.presentation
.xls application/vnd.ms-excel
These are the Office Open XML and legacy Excel MIME types, not custom MIME types.
2. Executa side: the MIME type must stay specific
Our Executa refuses to upload with a vague MIME type before it ever calls host/uploadFile:
if (typeof mimeType !== "string" || mimeType.trim().length === 0 || mimeType === "application/octet-stream") {
throw new Error(`Host Upload MIME type must be specific for ${safeFilename}`);
}
We keep this guard deliberately, which is relevant to this report. Sending application/octet-stream to get past the whitelist would work around a restriction the platform set on purpose, and it would also discard the format information that sheet_read and doc_read need in order to select the correct parser.
3. Agent side: the platform reader tools expect these formats
The analysis Agent is instructed to use sheet_read for .xlsx and .xls, and doc_read for .docx, .pptx, and .pdf, because those tools return structured output with stable locators such as A1 cell ranges and document block ids, which the Agent must cite. This is the documented way for an Agent to read structured source files, and it is why the upload has to preserve the real MIME type.
Issue: Office Document MIME Types Are Not in the Upload Token Whitelist
In a single session we uploaded four attachments, one after another. All four failed identically during negotiate. The PUT request was never issued.
The error in every case:
-32003 APP_PROVIDER_ERROR
mime '<type>' not in token whitelist
| File | MIME type sent | Result |
|---|---|---|
.pptx |
application/vnd.openxmlformats-officedocument.presentationml.presentation |
not in token whitelist |
.xlsx |
application/vnd.openxmlformats-officedocument.spreadsheetml.sheet |
not in token whitelist |
.docx |
application/vnd.openxmlformats-officedocument.wordprocessingml.document |
not in token whitelist |
.xls |
application/vnd.ms-excel |
not in token whitelist |
A verbatim entry from our storage transport log, for the .xlsx case:
{
"phase": "negotiate",
"status": "failed",
"source": "ppt-app.uploaded-source",
"purpose": "user_artifact",
"mime_type": "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet",
"size_bytes": 1924889,
"error": {
"name": "Error",
"code": "transport",
"message": "HTTP 400: {\"detail\":{\"code\":-32003,\"errorCode\":\"APP_PROVIDER_ERROR\",\"message\":\"mime 'application/vnd.openxmlformats-officedocument.spreadsheetml.sheet' not in token whitelist\"}}"
}
}
Control group: the same code path accepts images and PDF
In separate sessions on the same App, the same upload call, and the same purpose=user_artifact, these two succeeded end to end. The upload completed, the Agent read the file, and the analysis output was produced as expected:
image/jpeg
application/pdf
So the ingestion pipeline itself works. The only variable in the failing cases is the MIME type.
Our Understanding
This does not appear to be an upload failure in our App, nor an incorrect MIME type set by our code. The MIME types come from the browser for the user’s actual file and are the standard registered types for these formats.
The more likely explanation is that Anna Host Upload / App Provider does not include Office document MIME types in the allowed list when issuing the upload token.
What makes this worth reporting is that the platform already parses these exact formats. Anna provides sheet_read for .xlsx and .xls, and doc_read for .docx, .pptx, and .pdf. An Agent cannot call sheet_read on a spreadsheet that Host Upload refused to accept, so the reader tools and the upload policy currently contradict each other: the platform can read these formats, but will not let them in.
There is also no App-side fix available. The rejection happens during negotiate, before any bytes move, and the allowed MIME set is bound to the upload token issued by the platform. Nothing in the App bundle, the Executa, or either manifest can widen it.
Expected Behavior
We would expect Host Upload, either by default or through the corresponding grant configuration, to support the common Office document formats that Anna’s own reader tools already handle, at least:
application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
application/vnd.openxmlformats-officedocument.wordprocessingml.document
application/vnd.openxmlformats-officedocument.presentationml.presentation
application/vnd.ms-excel
They should also be allowed with purpose=user_artifact, because these are files the user explicitly selected as source material for the App to read.
If this must currently be enabled explicitly through an Admin grant or provider configuration, we would appreciate clarification on:
- At which layer allowed MIME types should be configured.
- Whether the App manifest or Executa manifest needs any additional declaration.
- Whether
host/uploadFileand the App runtimeupload.negotiate/upload.confirmAPIs share the same MIME whitelist.
Current Impact
Because the rejection happens before the file is persisted, the Workspace attachment directory is never created. From the user’s point of view, they select an .xlsx file and nothing happens: no attachment appears in the list, and no analysis runs. The reason is only visible in the transport log.
Concretely:
- Users cannot supply spreadsheets, Word documents, or existing decks as reference material, which is the most common form of real input for deck generation.
- Only images and PDF are usable today, so users must manually convert every Office file to PDF before uploading.
- The Agent’s
sheet_readanddoc_readcapabilities are effectively unreachable for user-uploaded files, even though the platform supports those formats.
What We Would Like to Confirm
We would like the Anna team to confirm:
- Should the standard Office document MIME types listed above be included in the Host Upload token whitelist?
- If this is not enabled by default, what is the configuration path available to App and Executa developers: the upload token, an Admin
upload_grant, the App manifest, or the Executa manifest? - What is the officially recommended end-to-end implementation for “let a user upload an Office document into an Anna App so an Agent can read it with sheet_read / doc_read”? If there is an official recommended approach we have missed, we can adjust the App implementation accordingly.
One additional observation on diagnosability: MIME rejection surfaces here as -32003 APP_PROVIDER_ERROR rather than the documented -32205 MIME_REJECTED. APP_PROVIDER_ERROR reads like a generic upstream failure, which made this harder to attribute to the whitelist than it needed to be.
Fixed — and more thoroughly than a whitelist patch
