Need Urgent Help: Facing Multiple Critical Bugs with My Anna App Build related to host.upload permission

rishabhbhartiya · June 19, 2026, 3:15am

The upload step is failing due to an Anna runtime/API mismatch.

Findings so far:

storage/files/upload_inline

Runtime returns:Method not found: ‘storage/files/upload_inline’

This indicates the endpoint is not implemented in the local runtime being used.

host/uploadFile

Runtime recognizes the method.

Previous response was:manifest does not grant ‘upload.inline’

This indicates the endpoint exists but requires permissions or a different runtime configuration.

Manifest has been updated with:

upload.inline

host.upload

The application is currently running on:

Anna CLI: v0.1.30

Runtime: anna-app-runtime-local@0.2.0a9

Storage backend: legacy (in-memory runtime_state)

Conclusion:

The blocker is determining the correct upload API and permission model supported by the current Anna runtime version. The local runtime appears to expose upload functionality differently than the documentation/examples being followed.

Request:

Could you confirm the currently supported file upload API for Executas/App Runtime and the required manifest permissions? Specifically whether uploads should use:

host/uploadFile

storage/files/upload_inline

storage/files/upload_begin

or another supported endpoint in the current runtime version.

hunter · June 19, 2026, 5:56am

Hi! Thanks for reporting this so carefully
I dug through the current Anna App / Executa upload and file-storage surfaces, and the good news is: this looks much more like an API-surface mismatch than a hard platform failure.

What’s actually happening

There are several Anna file/upload flows that look similar, but they are not interchangeable:

App UI host upload
- upload.inline
- upload.negotiate
- upload.confirm
Executa host upload
- host/uploadFile
APS Files persistent storage
- App side:
  - anna.files.upload_init
  - anna.files.upload_finalize
  - anna.files.download_url
- Executa side:
  - files/upload_begin
  - files/upload_complete
  - files/download_url

Because of that, storage/files/upload_inline is not the right method for the flow you’re trying to use, so Method not found on that name is expected.

The key conclusion

The root issue is not simply “upload is broken” or “the runtime does not support file upload.”

The real issue is:

one method name is being used against the wrong surface
the permission model being applied belongs to a different upload path
APS Files, app host upload, and Executa host upload are being treated as if they were one API

That’s why the behavior looks inconsistent at first glance.

Why your findings still matter

Your observations are still very useful

storage/files/upload_inline returning Method not found tells us that this exact method is not valid on the path being called.
host/uploadFile being recognized tells us the runtime does expose the Executa host-upload surface.
the earlier grant/permission error tells us that once the correct surface is reached, the next gate is authorization.

So the system is giving two different kinds of signals:

wrong method name
correct method family, but different grant/capability requirements

Permission clarification

This is the part that is easiest to mix up.

If you use `host/uploadFile`

This is the Executa host-upload path.

You need:

protocol v2
an Executa capability declaration like:
- host_capabilities: ["host.upload"]
the relevant upload grant enabled

If you use APS Files

This is the persistent storage/files path.

Use:

App side:
- anna.files.upload_init
- anna.files.upload_finalize
- anna.files.download_url
Executa side:
- files/upload_begin
- files/upload_complete
- files/download_url

If you use app-side direct upload

This is the App host API upload path.

Use:

upload.inline
upload.negotiate
upload.confirm

So adding both upload.inline and host.upload does not mean every file-related path is now enabled. Those names belong to different layers.

Which path should you choose?

Use APS Files if your goal is durable storage

For notes, saved files, user-owned persistent content, or anything that should survive beyond one temporary upload flow, use APS Files.

Use `host/uploadFile` if your goal is temporary/shareable artifacts

This is the right choice when an Executa wants to hand bytes back to the host without directly owning storage credentials.

Use app-side `upload.*` if your iframe/app is uploading directly

This is the host-mediated upload surface for the app UI itself.

Demo walkthrough you can try

To help make this concrete, I also tested the repo’s demo path and captured screenshots as a walkthrough example you can follow locally

These screenshots are reference walkthrough screenshots from our side, not evidence from your environment. They’re meant to show how you can play with the demo and validate the correct flow end-to-end.

Suggested way to play with the demo

Log in with the Anna App CLI
- Example: anna-app login --host https://anna.partners
  截屏2026-06-19 13.39.361868×840 145 KB
Push the demo app
- Example: anna-app apps push
  截屏2026-06-19 13.39.492290×1102 325 KB
In Anna, open the Agent / Plugin details and click Rediscover Local
- This makes sure the bundled Executa is loaded
  screenshot-20260619-1343441594×1284 150 KB
  
  screenshot-20260619-1344032154×1138 223 KB
Open the plugin permission dialog
- For the APS Files demo, enable Persistent Storage
  screenshot-20260619-1342531362×914 73.4 KB
Install the app’s working draft from Developer Console
- That makes the draft version available in chat
  screenshot-20260619-1341211944×832 70 KB
  screenshot-20260619-1342021924×1718 205 KB
Open the demo app in chat and test the save flow
- Enter a path like notes/hello.txt
- Enter some note text
- Click Save to APS Files
  screenshot-20260619-1344211774×1596 166 KB
  
  screenshot-20260619-1345271224×1468 76.5 KB
Optionally test:
- Get link
- List notes

If that flow succeeds, it strongly suggests the platform path is healthy and the remaining issue in a failing app is likely about API selection or permissions.

What the demo proves

If the APS Files demo works, that tells us a lot

It means:

local login is fine
the app draft install path is fine
the local rediscover path is fine
the Executa can be loaded correctly
Persistent Storage permission is being applied correctly
APS Files save/list/download behavior is working

That is why the repo examples are such a useful baseline.

Recommended repo examples to test

I strongly recommend testing against the examples in this repo first

Good starting points:

APS Files Demo
Files via Executa

These help separate two very different situations:

“the platform is broken”
“my app is calling the wrong file/upload surface”

If the examples work but your app does not, the next thing to compare is:

exact method name
whether the caller is App UI or Executa
manifest capability declaration
host API surface used
user/admin grant state

1. The finalization step for `host/uploadFile` is another `host/uploadFile` call

host/uploadFile is a self-contained surface. Every step — including the
completion — is the same method host/uploadFile, just with a different
mode. You never cross over into the APS Files files/* methods.

So your current flow:

1. host/uploadFile (negotiate) ✅ correct
2. PUT bytes to returned URL ✅ correct
3. storage/files/upload_complete ❌ wrong surface (APS Files)

should become:

host/uploadFile mode=negotiate → { put_url, headers, r2_key, expires_at }
PUT bytes to put_url with headers
host/uploadFile mode=confirm r2_key=… → { download_url, r2_key, size_bytes, expires_at }

files/upload_complete belongs to APS Files (persistent storage). It
finalizes an files/upload_begin, not a host/uploadFile. Because the two
surfaces were never meant to interleave, mixing them is exactly why you saw the
inconsistent behavior.

2. `host/uploadFile` is both — it depends on `mode`

There are three modes, and you pick based on file size / needs:

mode=inline → single call, returns the artifact URL directly.
Base64 payload, ≤ 8 MB. Simplest, one round-trip:
- host/uploadFile mode=inline { filename, mime_type, content_b64, purpose } → { download_url, r2_key, size_bytes, expires_at } done, no finalize

mode=negotiate + mode=confirm → negotiate → PUT → finalize.
Best for files > 8 MB or to avoid base64 overhead (this is your case):

host/uploadFile mode=negotiate → { put_url, headers, r2_key }
PUT bytes → put_url
host/uploadFile mode=confirm → { download_url, ... }

So: inline returns the URL directly; negotiate/confirm is the three-step flow.
Both return a transient download_url you can feed straight into
image/edit, sampling/createMessage, etc.

If you don’t need the >8MB path, switching to mode=inline removes the
finalize step entirely and is the quickest fix.

3. Where to declare `host_capabilities: ["host.upload"]`

This is the piece most people miss — it lives in two places, plus a grant:

a) The Executa plugin’s own manifest (the one returned by initialize /
describe). This is the reverse-capability negotiation. Without it, Anna Server side refuses the reverse-RPC with NOT_NEGOTIATED:

MANIFEST = {
  "display_name": "…",
  "version": "0.1.0",
  # ⬇️ this is the line you're probably missing
  "host_capabilities": ["host.upload"],
  "tools": [ … ],
}

(Same spot where the sampling example declares “host_capabilities”: [“llm.sample”].)

b) The App manifest ([manifest.json], schema 2) — list it under both
permissions and host_capabilities:

{
  "schema": 2,
  "permissions": ["…", "host.upload"],
  "host_capabilities": ["…", "host.upload"]
}

c) The user/admin grant must be enabled (the upload_grant) so the host
actually authorizes the bytes — MIME allowlist, per-file size cap, total quota.

If the plugin-side host_capabilities is missing but the app-side permission is
present, you’d see exactly the “method recognized but grant/permission error”
signal you described.

TL;DR

Finalize [host/uploadFile] with [host/uploadFile mode=confirm] — not
[files/upload_complete].
inline = one call; [negotiate] + [confirm] = three steps; both yield a
transient [download_url].
Declare [host_capabilities: [“host.upload”]] in the Executa manifest (most
likely your missing piece), mirror it in the app manifest, and make sure
the upload grant is on.

Want to be 100% sure your flow matches a known-good baseline? The Files via
Executa example uses the SDK’s [HostUploadClient] ([upload_inline] /
[negotiate] / [confirm]) and is the easiest reference to diff against. Happy to
look at your manifest + the exact call sequence if you paste them!

Munish · June 19, 2026, 7:18am

Hi! I implemented the changes you suggested and I’m still hitting a permission error before negotiate completes.

Current configuration:

Plugin manifest:

MANIFEST = {
    ...
    "host_capabilities": [
        "llm.sample",
        "storage.read",
        "storage.write",
        "host.upload"
    ]
}

App manifest:

{
  "permissions": [
    "tools.invoke",
    "storage.read",
    "storage.write",
    "chat.append_artifact",
    "host.upload"
  ],
  "host_capabilities": [
    "host.upload"
  ]
}

Current upload call sequence:

merge_and_finalize
  -> host/uploadFile(mode="negotiate")
  -> PUT bytes to returned URL
  -> host/uploadFile(mode="confirm", r2_key=...)

Relevant RPC code:

await self._send_and_wait(
    "host/uploadFile",
    {
        "mode": "negotiate",
        "content_type": mime,
        "size_bytes": size_bytes,
        "purpose": purpose,
        "invoke_id": invoke_id,
    }
)

Current runtime error:

RPC METHOD: host/uploadFile

RPC PARAMS:
{
  "mode": "negotiate",
  "content_type": "video/mp4",
  "size_bytes": 28801,
  "purpose": "animation",
  "invoke_id": "..."
}

RPC ERROR RAW:
{
  "code": -32603,
  "message": "manifest does not grant 'upload.inline'",
  "data": {
    "errorCode": "permission_denied"
  }
}

A few things confuse me:

I’m calling host/uploadFile, not upload.inline.
The plugin manifest already advertises host.upload.
The app manifest also includes host.upload.

Is host/uploadFile(mode=negotiate) expected to require the upload.inline grant internally?

Or is there another permission / capability / upload_grant that I still need to declare somewhere?
current runtime is anna-app-runtime-local@0.2.0a9.

hunter · June 19, 2026, 9:40am

Hey @Munish — you’ve now closed the two gates from before, so this last error is a different (third) gate, and it’s a sneaky one that’s specific to the local dev runtime. Great news: it’s a one-line manifest fix.

TL;DR

Add an upload entry to your app manifest.json under ui.host_api:

{
  "ui": {
    "host_api": {
      "tools":  ["required:<your-executa>"],
      "upload": ["inline", "negotiate", "confirm"]
    }
  }
}

That’s the piece anna-app-runtime-local@0.2.0a9 is asking for.

Why your error says `upload.inline` even though you called `negotiate`

In local dev, when your Executa fires the host/uploadFile reverse-RPC,
the runtime re-dispatches it through your app’s own iframe host-API ACL —
the exact same gate the iframe’s anna.upload.* calls go through. And the
runtime maps every host/uploadFile (regardless of mode) to the
canonical capability upload.inline for that ACL check.

So the check it runs is literally:

host_api_allows(app_manifest, ns="upload", method="inline")

When ui.host_api.upload is missing/empty, that returns false and you get:

{
  "code": -32603,
  "message": "manifest does not grant 'upload.inline'",
  "data": { "errorCode": "permission_denied" }
}

…which is exactly your runtime error. The mode=negotiate in your params is
fine — the message just always names upload.inline because that’s the ACL key.

The 3 gates, so you can see all of them at once

Gate	Where	Your status
1. Plugin advertises `host.upload`	Executa `MANIFEST.host_capabilities` (returned by `initialize`/`describe`)	you have this
2. `upload_grant.enabled`	per-user grant minted when `anna-app dev` registers your Executa	(signed-in)
3. App `ui.host_api.upload`	app `manifest.json` → `ui.host_api.upload`	← this one

Gate 3 is the local-runtime ACL you’re hitting now.

A note on prod vs. dev

In production, an Executa’s host/uploadFile rides on the Executa’s own
upload token straight to the host upload gate (host_capabilities + upload_grant),
so the app’s ui.host_api isn’t consulted there. The local runtime mirrors
upload through the app ACL for parity, which is why the manifest line is needed
to run it under anna-app dev. Declaring it is correct and harmless either way —
keep it in.

Reference baseline — grab it from the repo

There’s a full working example you can clone and diff against:

anna-executa-examples → anna-app-file-upload-demo

What to look at inside it:

The Executa (executas/file-upload-via-executa-python/) sources the bytes
itself — make_sample writes a scratch file, host_upload_path persists it via
host/uploadFile, auto-flipping inline (≤ 8 MiB, one base64 round-trip)
→ negotiate + confirm (presigned R2 PUT) as size crosses the cap. Bytes go
plugin → R2 directly, never back through tools.invoke.
The plugin MANIFEST declares host_capabilities: ["host.upload"].
manifest.json → ui.host_api is exactly where your upload array belongs.
Run it with plain anna-app dev (signed in) — host/uploadFile does not
need --storage aps.

Add the ui.host_api.upload line and your negotiate should sail straight
through to the presigned PUT. If it still snags, paste your full manifest.json
ui block + the exact negotiate→confirm sequence and I’ll diff it line by
line with you. Happy to dig in!

Munish · June 19, 2026, 3:51pm

I applied the changes:

Plugin MANIFEST contains:

“host_capabilities”: [
“llm.sample”,
“storage.read”,
“storage.write”,
“host.upload”
]

App manifest contains:

“host_api”: {
“upload”: [
“inline”,
“negotiate”,
“confirm”
]
}

host/uploadFile is now reaching the host successfully.

Current runtime error:

HTTP 403

{
“detail”: {
“code”: -32001,
“errorCode”: “APP_NOT_GRANTED”,
“message”: “upload_grant not enabled”
}
}

This happens for host/uploadFile mode=inline.

The previous errors about tool whitelisting and upload.inline permissions are gone.

Does this mean my local dev app/executa has not been issued an upload_grant yet? If so, how do I enable or mint the upload_grant for anna-app dev?

also
I compared my implementation with the official file-upload-via-executa example.

The upload flow now reaches host/uploadFile successfully and fails with:

APP_NOT_GRANTED
upload_grant not enabled

One thing I noticed is that the official example comments mention:

“user must also have upload_grant enabled on their UserExecuta.custom_config”

and the official demo works through a bundled Executa.

For a local dev Executa (tool-dev-manim-studio), is there a separate step required to mint or enable upload_grant for that Executa/account? Or should anna-app dev automatically provision it after registration?

Munish · June 20, 2026, 8:10am

update:
Hi, following up with a full status update after working through everything step by step.

What’s working

Authentication: anna-app whoami shows PAT valid (~85d), scope aps:dev — however user_id shows as (unknown), not sure if this is relevant
LLM calls: sampling/createMessage works perfectly with qwen3.7-plus (Manim code generates successfully)
Manim rendering: MP4 is rendered locally without issues
Executa published: tool-manishpathania092-tool-dev-manim-studio-kea37juj
App published: tool-dev-manim-studio, version 0.0.0-draft and 0.1.0 both show as Published in Developer Console

Current blockers

Blocker 1 — upload_grant not enabled (local dev)

Every time the pipeline reaches host/uploadFile mode=inline, it fails with:

HTTP 403: APP_NOT_GRANTED
upload_grant not enabled

This happens even after:

Adding host_capabilities: ["host.upload"] to executa.json
Adding ui.host_api.upload: ["inline", "negotiate", "confirm"] to manifest.json
Restarting anna-app dev while signed in

The upload request successfully reaches host/uploadFile — it fails only at the upload_grant check.

Blocker 2 — Manifest validation error

In the Developer Console, manifest validation shows:

{ "valid": false, "errors": ["manifest: Extra inputs are not permitted"] }

I suspect the top-level host_capabilities field may not be allowed in the app manifest schema. Should this only live inside ui.host_api, or also at the root level?

Blocker 3 — App not working on Anna platform

The app UI loads correctly on anna.partners/dashboard (Manim Studio opens, render settings show). But clicking Generate does nothing — no LLM call, no render. This works fine locally via anna-app dev. Is there something additional needed to connect the published executa to the published app?

Questions

Does upload_grant need to be manually enabled on my account or executa (tool-manishpathania092-tool-dev-manim-studio-kea37juj) by the Anna team? Or is there a CLI/dashboard step I’m missing?
Is user_id: (unknown) in anna-app whoami a problem? Could it be why upload_grant isn’t being provisioned?
What is the correct placement of host_capabilities: ["host.upload"] — root level of manifest.json, inside ui.host_api, or both?
What’s the correct flow to connect a published executa to a published app so it works on the Anna platform (not just locally)?

Environment:

CLI: anna-app v0.1.30
Runtime: anna-app-runtime-local@0.2.0a9
macOS
Published executa ID: tool-manishpathania092-tool-dev-manim-studio-kea37juj

Thank you!

HappyLight · June 20, 2026, 2:18pm

Hello, thank you for putting together such complete context and reproduction steps.

Regarding the error you are seeing now:

HTTP 403: APP_NOT_GRANTED
upload_grant not enabled

We have confirmed that this is an issue in the current local anna-app dev / local harness environment. Your request has already reached host/uploadFile, which means the earlier tool whitelist, ui.host_api.upload permission declaration, and host/uploadFile call path are basically correct. The failure happens at the local harness upload_grant check, where the upload grant is not currently provisioned correctly for the local dev app / executa.

We will fix this local harness issue as soon as possible and will update you here once the fix is available.

For now, the temporary workaround is to publish the demo to the Anna platform using anna-app apps push, as mentioned earlier. In the platform environment, the host/uploadFile upload flow should work normally and does not depend on local harness upload grant provisioning.

Also, regarding this manifest validation error:

{ "valid": false, "errors": ["manifest: Extra inputs are not permitted"] }

There is currently a small bug in the platform-side app manifest schema, and we will fix it later.

However, for your project, where a backend tool calls the upload capability through host/uploadFile, you do not need to put this at the root level of the app manifest.json:

"host_capabilities": ["host.upload"]

Keeping ui.host_api.upload in the app manifest.json is enough, for example:

"ui": {
  "host_api": {
    "upload": ["inline", "negotiate", "confirm"]
  }
}

If your backend Executa needs to call host/uploadFile, the corresponding capability should be declared in the Executa/plugin manifest, not at the root level of the app manifest.

Regarding the platform environment issue you mentioned:

App UI loads correctly on anna.partners/dashboard (Manim Studio opens and render settings are shown), but clicking Generate does nothing. There are no LLM calls and no rendering.

Could you confirm whether you published it to the platform using the anna-app apps push flow mentioned above? Also, when you click Generate, are there any console errors in the browser developer tools, or any network/runtime-related errors?

If convenient, please share the browser console error shown when clicking Generate, and we can continue checking whether the published app and published executa are connected correctly.

Munish · June 20, 2026, 4:25pm

yes i have done this using that flow.

and also changed the manifest.json as requested:

{

  "schema": 2,

"permissions": [

"tools.invoke",

"storage.read",

"storage.write",

"chat.append_artifact"

  ],

"required_executas": [

    { "tool_id": "tool-manishpathania092-tool-dev-manim-studio-k......j" }

  ],

"system_prompt_addendum": "You are Manim Studio — an AI animation director inside Anna. When the user asks for an animation or educational video:\n1. Call get_session_context to read user preferences.\n2. Call plan_animation to create a structured spec. Ask user for duration/language if not specified.\n3. Call generate_manim_code with the spec.\n4. Call render_animation, then poll get_render_status every 10s until done or failed.\n5. On render failure (status=failed, can_retry=true): call generate_manim_code again with error and prev_code. Max 3 retries.\n6. Call generate_audio with the narration_script.\n7. Call merge_and_finalize to produce the final video_url.\n8. Call update_session_memory with the outcome.\n9. Append an artifact to chat with the video_url and download link.\nAlways tell the user what step you are on. Be friendly and informative during the 1-2 minute wait.",

"ui": {

"bundle": { "format": "static-spa", "entry": "index.html" },

"csp_overrides": {

"script-src": ["'sha256-8V6j/CWIkpAGNv/z+7l7m4/bh1yWbTzKd0XJpDPXW6M='"]

  },

"views": [

      {

"name": "main",

"title": "Manim Studio",

"default": true,

"default_size": { "w": 1280, "h": 800 },

"min_size":     { "w": 800,  "h": 600 },

"single_instance": true,

"summary_template": "Manim Studio: {topic}"

      }

    ],

"host_api": {

"tools": ["required:tool-manishpathania092-tool-dev-manim-studio-k.....uj"],

"upload": ["inline", "negotiate", "confirm"],

"storage": ["get", "set", "delete", "list"],

"chat": ["append_artifact"],

"llm": ["complete"],

"agent": {

"session": { "auto": true },

"tools": [

"tool-manishpathania092-tool-dev-manim-studio-k.......j"

        ]

      }

    }

  },

"dev": {

"seed_storage": {

"render_history": []

    }

  }

}

this is my current error:

and regarding this error -

[UPLOAD] starting inline upload size=28801

[host-rpc] RPC METHOD: host/uploadFile

HTTP 403

{
"detail": {
"code": -32001,
"errorCode": "APP_NOT_GRANTED",
"message": "upload_grant not enabled"
}
}

its a schema mismatch and will solved in how much duration as my app depends upon this

HappyLight · June 21, 2026, 7:06am

It looks like Anna App’s CSP is blocking your inline script.

The actual issue in the screenshot is this red error:

Executing inline script violates the following Content Security Policy directive: script-src 'self' ...

It points to line 265 in the app bundle’s index.html. Usually this means the HTML contains something like:

<script type="module">
  // some JS here
</script>

But Anna App UI bundles use a stricter CSP by default: scripts should be loaded from same-origin external files, for example:

<script src="app.js" type="module"></script>

Then put the runtime code in app.js:

import { AnnaAppRuntime } from "/static/anna-apps/_sdk/latest/index.js";

const anna = await AnnaAppRuntime.connect();

So I’d suggest checking line 265 in index.html and moving that inline script into a separate app.js file. The official Anna App UI examples generally follow this pattern.

Munish · June 21, 2026, 7:42am

App loads correctly, app.js works, no more CSP errors. But clicking Generate gives:

Error: no Executa Agent is currently online for this user

The published executa tool-manishpathania092-tool-dev-manim-studio-kea37juj (v0.1.0) is frozen in version 0.1.9 of the app. But it appears to not be running server-side on Anna’s platform.

Questions:

After anna-app executa publish, does Anna automatically host and run the Python executa on Anna’s servers? Or does it need to be deployed separately?
Is there a hosting/deployment step I’m missing to get the executa running in production?
Is Python executa hosting currently supported on Anna’s platform, or is this a feature still in development?

i have pushed the exceuta -

anna-app apps push --manifest manifest.json                                                                                                   ─╯
anna-app apps cut 0.1.9

▀▀▀▀▀██▀▀██▀▀▀▀▀  Anna  Anna App developer CLI
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀  › v0.1.30 — apps push --manifest manifest.json
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀

using PAT from credentials (host=https://anna.partners)
staging working bundle: 3 files, 172.4 KB
✓ working bundle staged (3 files, status=ready)
✓ apps/tool-dev-manim-studio: working draft updated (rev 10)
✓ working bundle: 3 files, 172.4 KB → ready
status: published
(uncommitted changes vs latest cut version)
→ install & test the draft (reserved 0.0.0-draft) from the Developer Console
→ run anna-app apps cut 0.1.0 to snapshot an immutable version
▀▀▀▀▀██▀▀██▀▀▀▀▀  Anna  Anna App developer CLI
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀  › v0.1.30 — apps cut 0.1.9
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀

✓ apps/tool-dev-manim-studio: cut immutable version 0.1.9 (version_id=333)
froze tool-manishpathania092-tool-dev-manim-studio-kea37juj → executa_version=124 (v0.1.0)
→ run anna-app apps release 0.1.9 to go live
status: published

And in the Developer Console the toolId id mentioned.

Another error the problem of upload grant still cause the app to fail in local : [executa:tool-manishpathania092-tool-dev-manim-studio-kea37juj] manim_studio.host_rpc.RPCError: HTTP 403: {"detail":{"code":-32001,"errorCode":"APP_NOT_GRANTED","message":"upload_grant not enabled"}}
**So when will this resolved as my Submission date approaching.

Another think i got the feedback that our app “**i noticing is when the prod team tested and my app it does not work and they say - We did install the latest app version, but the issue is still on the tool side, not the app side.
The run log is still showing the tool as v0.1.0 with empty distribution metadata (pkg=x, binary_urls=x), so Anna Agent still has nothing installable for the tool.
In other words, this looks like the Executa distribution config has not been updated correctly yet, even though the app version itself is newer.”

my exceuta.json is currentlt this - {
"tool_id": "tool-dev-manim-studio",
"slug": "tool-dev-manim-studio",
"type": "python",
"enabled": true,
"host_capabilities": ["host.upload"],
"run": ["python", "-m", "manim_studio.plugin"]
}

So Anna doesn’t host Python executas server-side. The executa needs binary distribution (binary_urls) to run on users’ machines.

My executa.json currently only has a run command for local dev. For production, I need to:

Build a PyInstaller binary of my executa
Host it at public URLs
Add binary_urls to my executa config with per-platform download links

Question: **My executa uses Manim (which requires LaTeX, ffmpeg, Cairo, and other system dependencies). Is PyInstaller --onedir the right approach here, or is there a simpler way to distribute Python executas with heavy system dependencies on Anna’s platform?

as per docs - Anna does NOT automatically host Python executas server-side**.Executas run as local processes on the user’s machine (or a server the developer hosts). The docs say:

“The binary lives wherever the user installed it”

This means your executa needs binary distribution — my executa has no binary distribution configured I think this is the issue if yes how to add this?

hunter · June 21, 2026, 10:36am

Hey @Munish! Great debugging work — you actually diagnosed this exactly right, so let me confirm it and point you to the fastest path forward.

Why you’re seeing `no Executa Agent is currently online`

You nailed it here:

So Anna doesn’t host Python executas server-side. The executa needs binary distribution (binary_urls) to run on users’ machines.

That’s 100% correct. Today, Anna does not auto-run your Python executa on our servers. An executa is an independent process that the Agent starts on a machine and talks to over stdio JSON-RPC. Your run log saying pkg=x, binary_urls=x is the real signal — the tool was cut at v0.1.0 with empty distribution metadata, so Anna Agent has nothing installable. That’s why no agent ever comes online, and it’s unrelated to your app version.

The fix: configure binary distribution

Your executa.json currently only has a local run command (perfect for dev, not for prod). For production you need a per-platform binary that the Agent can download, extract, and launch.

We just published a full hands-on, step-by-step guide that walks through exactly this — PyInstaller → .tar.gz → GitHub Release → binary_urls:

Don’t Just Run Locally: Packaging Anna Executa as a Releasable Binary

The short version:

Build a PyInstaller binary of your executa (CI builds one per platform — PyInstaller can’t cross-compile)
Upload the .tar.gz assets to a GitHub Release in your own fork
In the Tool config (More → Advanced → Executa), set Distribution Type = Binary and add the per-platform download URLs (darwin-arm64, darwin-x86_64, linux-x86_64)
On your Agent (More → Agents), click Install Essentials — Details should then show Binary / Running

One thing to double-check from the guide: make sure your archive’s manifest.json entrypoint points to the real path inside the archive (e.g. bin/<tool_id>), and that the binary answers describe over stdio before you ship it.

On Manim + LaTeX / ffmpeg / Cairo

Good question — for heavy system dependencies, --onedir is the better choice over --onefile: faster cold start, easier to inspect, and far fewer “missing dylib” surprises. The archive layout in the guide (bin/, plus optional lib/, data/) is designed exactly for this multi-file case. A couple of practical notes:

Pure-Python deps bundle cleanly with PyInstaller.
True system binaries like ffmpeg and a LaTeX toolchain are large and not Python packages — the most reliable approach is to ship/locate the binaries your tool shells out to (bundle ffmpeg in your archive and point to it; document/guard the LaTeX requirement) rather than expecting PyInstaller to capture them automatically.

About a server-side runtime

You mentioned wanting Anna to run the executa server-side — that’s coming! We’re rolling out Cloud Agents (a hosted, server-side runtime for executas) within the next ~2 weeks. That will give you a path where heavy executas can run on Anna-managed infrastructure instead of every user’s machine. For your current submission deadline, binary distribution is the supported route today and will keep working great alongside Cloud Agents once it lands.

Quick note on the `host.upload` 403

The APP_NOT_GRANTED: upload_grant not enabled you hit locally is a separate permission-grant issue from the distribution problem above — once your tool actually comes online via binary, grant host.upload to the app and that path should clear. If it still trips after that, drop the exact CLI/runtime versions in a reply and we’ll dig in.

You’re very close — getting binary_urls populated is the missing piece. Ping us here if Details still shows Not Installed after configuring, and share the platform key + the URL you used so we can spot any mismatch. You’ve got this!

Munish · June 21, 2026, 7:16pm

Hi,

I’ve completed the binary packaging and publishing flow for the Manim Studio Executa and wanted to report the current status and blockers.

What’s Working

Executa is publishing successfully.
Binary distribution is configured and published.
Multi-platform binaries are built through GitHub Actions:
- Linux x86_64
- macOS Intel (darwin-x86_64)
- macOS Apple Silicon (darwin-arm64)
Binary artifacts are being mirrored into Anna storage.
Executa versions are freezing correctly during app cuts.
App version 0.2.0 was successfully cut and references Executa v0.1.2.
Local development runtime works correctly via anna-app dev.
Tool invocation, LLM calls, code generation, rendering pipeline, and host RPC communication are functioning.

Current Platform Issues

1. Binary download and installation appear successful. Manual execution works and returns tool metadata. However, the Agent rediscover step fails with “describe returned no manifest”. The binary currently emits startup logs to stdout before JSON-RPC responses, and the describe response may not match the manifest structure expected by Anna Agent. These are the two leading causes remaining.

2.host/uploadFile Permission Failure

When rendering locally, the pipeline completes until the final upload step and then fails with:

{
  "errorCode": "APP_NOT_GRANTED",
  "message": "upload_grant not enabled"
}

The RPC call failing is:

host/uploadFile

The stack trace indicates the failure occurs during:

host_upload_inline(...)

used by the final video upload step.

Question:

Is there an app-level permission or manifest setting required to enable host.upload?
Do I need additional grants beyond the declared capability?

Additional Context

The app manifest currently declares:

"host_capabilities": [
  "llm.sample",
  "storage.read",
  "storage.write",
  "host.upload"
]

and the Executa version metadata shows:

supports protocol: yes
distribution type: binary
binary successfully mirrored

So at this point the remaining blockers appear to be:

Agent registration/connection.
Upload grant permissions.

Could you advise the expected setup for Agent registration and the required configuration for enabling host/uploadFile?

Munish · June 21, 2026, 7:17pm

Additional-

Munish · June 22, 2026, 8:04am

I verified the binary packaging end-to-end:

GitHub Release archive contains manifest.json
runtime.binary.entrypoint points to a valid executable
binary downloads and extracts correctly
executable launches successfully
manual JSON-RPC describe call succeeds and returns tool metadata

However Agent discovery still fails with:

describe returned no manifest

Agent log:

/Users/.../tool-manishpathania092-tool-dev-manim-studio-kea37juj:
describe returned no manifest

I suspect either:

the current Executa protocol expects a different describe response schema than the one returned by my plugin;
the returned manifest must be wrapped under a specific field (e.g. manifest);
the plugin manifest returned by describe must match the packaged manifest.json name/version exactly.

Could you share a working binary Executa example or the expected describe response schema used by Agent discovery?
do i have any entry point problem or what i cant get through it.

Topic		Replies	Views
`host_upload_path` returns `APP_NOT_GRANTED` when debugging the official file upload demo with `anna-app dev` Developers	0	12	July 3, 2026
`anna-app dev --storage aps` fails when an App invokes an Executa using APS Files, while direct Executa testing succeeds Developers dev-kit	1	45	June 10, 2026
Don't Just Run Locally: A Hands-on Guide to Packaging Anna Executa as a Releasable Binary Developers	0	121	June 19, 2026
[Bug] host.upload vs storage/files/upload_inline API & Permission Mismatch on Local Runtime v0.2.0a9 Developers	1	35	June 19, 2026
Platform-assigned Executa versions conflict with local versions during `anna-app apps publish`, and failed retries quickly hit the upload rate limit Developers	2	18	July 10, 2026

Need Urgent Help: Facing Multiple Critical Bugs with My Anna App Build related to host.upload permission

What’s actually happening

The key conclusion

Why your findings still matter

Permission clarification

If you use `host/uploadFile`

If you use APS Files

If you use app-side direct upload

Which path should you choose?

Use APS Files if your goal is durable storage

Use `host/uploadFile` if your goal is temporary/shareable artifacts

Use app-side `upload.*` if your iframe/app is uploading directly

Demo walkthrough you can try

Suggested way to play with the demo

What the demo proves

Recommended repo examples to test

Suggested reply you can post

What’s going on

Why the results look inconsistent

Permission clarification

Best next step

Helpful demo flow

1. The finalization step for `host/uploadFile` is another `host/uploadFile` call

2. `host/uploadFile` is both — it depends on `mode`

3. Where to declare `host_capabilities: ["host.upload"]`

TL;DR

TL;DR

Why your error says `upload.inline` even though you called `negotiate`

The 3 gates, so you can see all of them at once

A note on prod vs. dev

Reference baseline — grab it from the repo

Why you’re seeing `no Executa Agent is currently online`

The fix: configure binary distribution

On Manim + LaTeX / ffmpeg / Cairo

About a server-side runtime

Quick note on the `host.upload` 403

What’s Working

Current Platform Issues

2.host/uploadFile Permission Failure

Additional Context

Need Urgent Help: Facing Multiple Critical Bugs with My Anna App Build related to host.upload permission

What’s actually happening

The key conclusion

Why your findings still matter

Permission clarification

If you use host/uploadFile

If you use APS Files

If you use app-side direct upload

Which path should you choose?

Use APS Files if your goal is durable storage

Use host/uploadFile if your goal is temporary/shareable artifacts

Use app-side upload.* if your iframe/app is uploading directly

Demo walkthrough you can try

Suggested way to play with the demo

What the demo proves

Recommended repo examples to test

Suggested reply you can post

What’s going on

Why the results look inconsistent

Permission clarification

Best next step

Helpful demo flow

1. The finalization step for host/uploadFile is another host/uploadFile call

2. host/uploadFile is both — it depends on mode

3. Where to declare host_capabilities: ["host.upload"]

TL;DR

TL;DR

Why your error says upload.inline even though you called negotiate

The 3 gates, so you can see all of them at once

A note on prod vs. dev

Reference baseline — grab it from the repo

Why you’re seeing no Executa Agent is currently online

The fix: configure binary distribution

On Manim + LaTeX / ffmpeg / Cairo

About a server-side runtime

Quick note on the host.upload 403

What’s Working

Current Platform Issues

2.host/uploadFile Permission Failure

Additional Context

Related topics

If you use `host/uploadFile`

Use `host/uploadFile` if your goal is temporary/shareable artifacts

Use app-side `upload.*` if your iframe/app is uploading directly

1. The finalization step for `host/uploadFile` is another `host/uploadFile` call

2. `host/uploadFile` is both — it depends on `mode`

3. Where to declare `host_capabilities: ["host.upload"]`

Why your error says `upload.inline` even though you called `negotiate`

Why you’re seeing `no Executa Agent is currently online`

Quick note on the `host.upload` 403