# Feedback: Standard Office Document MIME Types Are Rejected by the Host Upload Token Whitelist in Anna App **URL:** \ **Category:** Developers\ **Created:** [August 12, 2026, 4:59am UTC](https://forum.anna.partners/t/feedback-standard-office-document-mime-types-are-rejected-by-the-host-upload-token-whitelist-in-anna-app/218 "2026-08-12T04:59:45Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![Silicon](https://avatars.discourse-cdn.com/v4/letter/s/b4bc9f/32.png) [@Silicon](https://forum.anna.partners/u/Silicon)\ **Post date:** [August 12, 2026, 4:59am UTC](https://forum.anna.partners/t/feedback-standard-office-document-mime-types-are-rejected-by-the-host-upload-token-whitelist-in-anna-app/218/1 "2026-08-12T04:59:45Z")
## **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: ```auto 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: ```auto 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: ```auto .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`: ```auto 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: ```auto -32003 APP_PROVIDER_ERROR mime '' 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: ```auto { "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: ```auto 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: ```auto 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/uploadFile` and the App runtime `upload.negotiate` / `upload.confirm` APIs 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_read` and `doc_read` capabilities 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: 1. Should the standard Office document MIME types listed above be included in the Host Upload token whitelist? 2. 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? 3. 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. ---
**Author:** ![hunter](https://yyz1.discourse-cdn.com/flex033/user_avatar/forum.anna.partners/hunter/32/8_2.png) [@hunter](https://forum.anna.partners/u/hunter)\ **Post date:** [August 17, 2026, 7:23am UTC](https://forum.anna.partners/t/feedback-standard-office-document-mime-types-are-rejected-by-the-host-upload-token-whitelist-in-anna-app/218/2 "2026-08-17T07:23:06Z")
Hey @silicon! 👋 Thank you for this outstanding report — the controlled comparison (images/PDF passing on the exact same path), the verbatim transport logs, and your refusal to work around it with `application/octet-stream` made the diagnosis instant. This is exactly how we hope platform feedback looks. 🏆 You were right on both counts, and both are **fixed as of v1.1.0-beta.128** (already live). 🎉 **1. Office MIME types rejected at `negotiate`** ✅ Fixed — and more thoroughly than a whitelist patch You correctly spotted the contradiction: the platform ships `sheet_read` / `doc_read` for exactly these formats, yet Host Upload wouldn’t let them in. After reviewing the design, we concluded the MIME whitelist itself was the bug — with self-reported MIME types it was never a real security control, it only punished honest apps like yours. So in beta.128 we **removed the MIME whitelist entirely**. 🧹 - `.xlsx`, `.xls`, `.docx`, `.pptx` (and any other honest MIME type) now upload fine with `purpose=user_artifact` — no config, no manifest declaration, no admin grant needed - The change applies to existing installs immediately; nothing on your side to migrate - What remains: a hard blacklist for genuinely dangerous types (executables, SVG) and the purpose checks — those are enforced server-side at serve time, not via self-reported MIME **2. `-32003 APP_PROVIDER_ERROR` instead of `-32205 MIME_REJECTED`** ✅ Fixed Great catch on diagnosability. The App runtime `upload.negotiate` / `upload.confirm` path was collapsing all upload errors into the generic `-32003`. As of beta.128 you’ll get the documented semantic codes: `-32205 UPLOAD_MIME_REJECTED` (now only triggered by the hard blacklist), `-32204 UPLOAD_TOO_LARGE`, and `-32206 UPLOAD_PURPOSE_REJECTED`. 🔍 **To your question 3** — your pipeline (`anna.upload` → `HostUploadRef` → commit to Workspace → Agent reads via `sheet_read` / `doc_read`) is exactly the recommended approach, and your Executa’s “MIME must stay specific” guard is the right call: keep it. With beta.128 the whole flow should now work end to end for Office documents. ✨ Please give it a spin and let us know if anything else gets in the way — reports like this one make the platform better for every builder. 🙏 Happy building! 🚀📊