Add an `apps/` catalog for Agent Canvas Apps

[DevinVinson]

Why

OpenHands Apps are installable interfaces that bring a team’s tools and workflows directly into Agent Canvas. They are powered by the Canvas Extensions API, introduced as a beta feature in Agent Canvas 1.16.

The current beta supports custom pages that appear in the Agent Canvas sidebar and can connect to the active Agent Server through its authenticated HTTP helper. This enables teams to add dashboards, internal tools, and project-specific workflows to Canvas without maintaining a fork.

We should use Apps as the user-facing category in this repository:

• It is clearer to people outside the developer audience.
• It distinguishes UI contributions from skills (agent instructions and knowledge) and plugins (agent capabilities and configuration).
• It gives the category room to grow beyond custom pages as the Canvas Extensions platform evolves.
• It aligns this registry with the Agent Canvas product language: “Apps for Agent Canvas,” “Add app,” and “Installed apps.”

Adding an apps/ directory to this registry will make community and OpenHands-built Apps discoverable alongside the repository’s existing reusable extensions. Users will have a single, familiar place to find and share skills, plugins, integrations, automations, and now Agent Canvas Apps.

Desired Behavior

Establish a first-class, discoverable Apps catalog in this repository using the existing Canvas Extension package format and catalog workflows, while preserving the current skills, plugins, integrations, and automations catalogs.

Scope

• Add a top-level apps/ directory to the repository.
• Define a lightweight, documented convention for one App per directory.
• Make each App directory contain a valid Canvas Extension package, beginning with:
  • canvas-extension.json
  • its declared browser ESM entrypoint exporting activate
  • optional App-specific documentation and assets
• Add Apps to the repository’s discovery and catalog surfaces so users can browse them as they do skills and plugins.
• Use Apps as the public-facing label while accurately describing the underlying Canvas Extensions API and its beta status.
• Include clear trust guidance: Apps run trusted JavaScript inside Agent Canvas and can make authenticated requests to the active Agent Server; users should review source and resolved revision before enabling them.

Non-goals

• Renaming or moving the existing skills/, plugins/, integrations/, or automations/ catalogs.
• Expanding the Canvas Extensions API beyond the currently supported custom-page beta.
• Supporting a hosted App marketplace, remote execution, or a permission model beyond what Agent Canvas currently provides.
• Treating Apps as equivalent to agent skills or plugins.

Acceptance Criteria

• The repository has a top-level apps/ directory with documented contribution conventions.
• An App can be added as a self-contained Canvas Extension package following the Agent Canvas manifest and host API contract.
• Repository documentation explains what Apps are, how they differ from skills and plugins, and how users discover/install them.
• Apps have a discoverable catalog surface consistent with the rest of this repository.
• The public copy uses the approved positioning: Apps are installable interfaces that bring dashboards, internal tools, and workflows directly into Agent Canvas without requiring a fork.
• Documentation and catalog language indicate that Apps are powered by the Canvas Extensions API and that the feature remains beta.
• User-facing trust guidance clearly states that enabling an App executes trusted JavaScript in the Agent Canvas browser context and enables authenticated requests to the active Agent Server.

---

This issue was created by an AI agent (OpenHands) on behalf of the user.

Maintainer authorization for stacked implementation

Graham Neubig explicitly authorized stacked implementation before prerequisite issues close. Dependencies above are merge-order constraints, not closed-issue requirements for implementation readiness. Please evaluate scope readiness independently; do not close prerequisite issues or waive validation. Use native GitHub stacks for same-repository PR chains and explicit links for cross-repository dependencies.

This update was made by an AI agent (OpenHands) on behalf of Graham Neubig.

[github-actions]

⚠️ Not yet ready-for-dev

This issue does not yet meet the readiness criteria, so the
ready-for-dev label has not been applied (or has been removed).
The criteria are type-specific:

Bug reports (bug label):

• The ### Actual Behavior section must describe reproducible steps
  and include a command such as uv run pytest, pytest, python,
  pip, npm run, or node.
• An ### Acceptance Criteria section with at least one checklist item (- [ ] ...).

Enhancements (enhancement label):

• A ### Desired Behavior section.
• An ### Acceptance Criteria section with at least one checklist item.

What is missing:

• The issue has neither the bug nor enhancement label, so its readiness criteria cannot be evaluated. Add the appropriate label.

Edit the issue to address the gaps and the ready-for-dev label will be
applied automatically.

This is an automated readiness check posted by a workflow.

[enyst]

I think Apps is an excellent name, even if, well, it’s apps 😅

Maybe we can adjust more, before making it a public recommended format, e.g. rename to openhands-app.json or app.json. Otherwise we’d have some migration headaches, it seems to me.

[DevinVinson]

I personally like the framing of using the canvas extensions api especially if we add more places apps can integrate with canvas. Not a super strong opinion on it but it was intentional :)

I'll do a quick check and see where that refactor would touch.

[DevinVinson]

Seems like it would be a find and replace change everywhere in the SDK that refers to this. Then all the tests. IMO just changing the frontend name is fine and keeping the underlying canvas-extension references.