Cteno Open Platform

Declarative capability packages for building your own Agent OS plugins.

The open platform is for plugin developers, not a list of currently bundled integrations. A developer declares identity, Skills, CLI/MCP, authentication, recommendations, permissions, and distribution in a manifest; Cteno handles installation verification, enable state, workspace projection, PATH injection, runtime gating, and human confirmation.

Manifest

.cteno-plugin/plugin.json

Surfaces

Skill · CLI · MCP · Auth · Recommendations

Install Path

Package · Download · Daemon Install

Governance

Permissions · Scope · Gating

Capability Sections

5

Declaration Items

22

Developer Surfaces

5+

Cloud Skill

Install the developer Skill first, then ask Cteno to generate your own plugin.

`cteno-plugin-dev` is a cloud-distributed developer assistant Skill. Once installed, it appears in Cteno's Skill list and guides developers through business discovery, manifest design, SKILL.md authoring, CLI/MCP surfaces, auth/status handling, permission boundaries, packaging, and local install verification.

This Skill helps developers create new plugins. It is not a catalog of existing external integrations.

Cloud Distribution

Cloud-hosted

The Skill ships as a standard plugin package through Happy Server endpoints; the site never exposes OSS URLs.

/v1/plugins/cteno-plugin-dev/index

Cteno Deeplink

One-click launch

The install button opens local Cteno through a deeplink and passes the package indexUrl into the install flow.

cteno://plugins/install?pluginId=cteno-plugin-dev&indexUrl=%2Fv1%2Fplugins%2Fcteno-plugin-dev%2Findex

Manual Download

Manual fallback

The download button fetches the `.cteno-plugin.zip` package for manual import or CLI-based installation.

/v1/plugins/cteno-plugin-dev/download?platform=all

Plugin Contract

Manifest Declaration

The single declaration entry is `.cteno-plugin/plugin.json`. It defines identity, distribution, default enablement, agent-facing surfaces, and required permissions.

Plugin Identity

Declaration

schemaVersion, id, version, title, description, defaultEnabled

What Cteno Provides

Cteno uses these fields to identify a plugin, display cards, compare versions, and decide default enablement.

Developer Usage

Keep id stable; bump version with package releases; write description for users and developers, not as an execution manual.

Governance

id/version are part of install cache and update selection and should not drift at runtime.

Package Source

Declaration

package.source, package.channel, package.indexUrl

What Cteno Provides

Declares where the plugin is obtained. Clients fetch controlled artifacts through Happy Server endpoints.

Developer Usage

Use stable for public releases, separate channels for experiments, and point indexUrl at the platform distribution API.

Governance

Clients do not access private OSS directly; the daemon verifies archives, checksums, and path traversal.

Surface Root

Declaration

surfaces.prompt, surfaces.externalCli, surfaces.auth, surfaces.recommendations, surfaces.mcp

What Cteno Provides

Groups agent context, executable commands, auth entry, recommended tasks, and MCP tools into one manifest block.

Developer Usage

Declare only the surfaces the plugin actually supports.

Governance

Disabling a plugin must disable every surface together.

Permissions

Declaration

permissions.externalProcess, permissions.network, permissions.filesystem

What Cteno Provides

The plugin UI and daemon gating read this declaration to show process, network, and filesystem boundaries.

Developer Usage

List the main binary, official command names, and compatibility aliases in externalProcess.

Governance

Undeclared execution surfaces should not be reachable through wrappers or agent instructions.

Capability Surfaces

Declarative Capability Surfaces

Developers declare surfaces; Cteno projects them to the agent, GUI, runtime PATH, MCP layer, and permission system.

Skill / Prompt Fragment

Declaration

surfaces.prompt.fragments[]

What Cteno Provides

Projects plugin instructions to the agent: when to use it, how to call it, and what business boundaries apply.

Developer Usage

Each fragment points to `skills/<skill-id>/SKILL.md`; related references/scripts/assets live next to it.

Governance

Project the full skill directory, not only SKILL.md, so relative references keep working.

External CLI

Declaration

surfaces.externalCli.binary, statusCommand, authCommand, ...

What Cteno Provides

Declares the stable command surface. Cteno injects plugin PATH for agent subprocesses.

Developer Usage

Use wrappers/shims for official command names, aliases, and platform differences; prefer JSON output.

Governance

Status output is normalized by the wrapper, not by GUI-specific parsers.

Auth Action

Declaration

surfaces.auth.command, surfaces.auth.description

What Cteno Provides

The plugin page can show a connect-account action that the daemon runs in a visible terminal.

Developer Usage

Put OAuth, QR login, and bot-secret setup in auth.command.

Governance

Interactive login must never run hidden in a background shell.

Recommendations

Declaration

surfaces.recommendations[]

What Cteno Provides

Turns common business workflows into launchable cards that send a prepared prompt to the agent.

Developer Usage

Each card includes id, title, description, prompt, and optional icon/color.

Governance

Recommendation prompts should state that writes, sends, deletes, and approvals need confirmation.

MCP Servers

Declaration

surfaces.mcp.servers[]

What Cteno Provides

Exposes standard tool surfaces that can be projected alongside CLI and native tools.

Developer Usage

Use MCP for structured tools, long-lived tool servers, and cross-client compatibility.

Governance

MCP projection follows plugin enable state and must disappear when the plugin is disabled.

Host / Native Capabilities

Declaration

future host capability surface / daemon RPC capability

What Cteno Provides

Host-owned features such as browser, memory, files, and scheduling can be exposed through runtime-native boundaries.

Developer Usage

Business plugins should prefer CLI/MCP; use daemon RPC only for host-owned state.

Governance

Plugin sidecars must not write daemon SQLite or bypass permission flows.

Package & Distribution

Package and Distribution

Source folders are for development and packaging. Runtime installs use `.cteno-plugin.zip` archives unpacked by the daemon into the data-dir cache.

Plugin Folder Layout

Declaration

plugins/<id>/.cteno-plugin/plugin.json, skills/, bin/, mcp/

What Cteno Provides

Cteno recognizes a standard manifest, skill directory, binary/wrapper directories, MCP declarations, and assets.

Developer Usage

Keep references/scripts/assets beside each skill; put binaries under all/ or platform-specific folders.

Governance

Manifest resource paths must resolve inside the plugin root.

Package Script

Declaration

scripts/package-plugin.sh <plugin-id>

What Cteno Provides

Produces versioned archives, manifests, sha256 values, and dist/plugins index files.

Developer Usage

Update CLI, Skill, wrapper, manifest version, and artifact index in one release batch.

Governance

Platform directories, index platform names, and sha256 values must match.

Distribution APIs

Declaration

GET /v1/plugins/:pluginId/index | manifest | download

What Cteno Provides

Happy Server reads OSS indexes, selects artifacts by version/platform, and returns controlled endpoints.

Developer Usage

Plugin marketplaces or installers call Happy Server endpoints, not raw OSS URLs.

Governance

Buckets may stay private; clients do not hold OSS credentials or signing logic.

Install RPC

Declaration

<machineId>:install-host-plugin-package

What Cteno Provides

The GUI hands the downloaded archive to the daemon; daemon verifies, unpacks, and writes runtime cache.

Developer Usage

Install params include pluginId, version, platform, archiveBase64, and optional sha256.

Governance

Daemon checks source, version, checksum/signature, and path traversal.

Runtime Projection

Runtime Projection

Once enabled, Cteno builds an effective projection: the agent sees Skills, subprocesses get PATH, GUI sees recommendations and permissions, and MCP/CLI follow one enable switch.

Effective Enable State

Declaration

builtin default + global setting + workspace override + session policy

What Cteno Provides

Cteno computes plugin availability per workspace instead of baking it into a session.

Developer Usage

Test global enable, workspace disable, and workspace-only enable paths.

Governance

Disabling must remove prompts, MCP, CLI/native tools, daemon RPC, and recommendations.

Workspace Skill Projection

Declaration

{workdir}/.cteno/plugin-skills/<skill-id>/

What Cteno Provides

Before session start, enabled plugin skills are copied into the workspace canonical projection path.

Developer Usage

Use relative references in skills so references/scripts/assets work after projection.

Governance

Projection markers prevent disabled plugin skills from being re-scanned as user skills.

CLI PATH Injection

Declaration

bin/<runtime-platform>/, bin/all/, bin/

What Cteno Provides

Daemon injects existing plugin CLI directories for enabled plugins and declared binaries.

Developer Usage

Cover the main command, official names, historical aliases, and Windows .cmd/.exe where needed.

Governance

GUI never builds plugin absolute paths; commands resolve through plugin PATH.

Status JSON Normalization

Declaration

authenticated | connected | logged_in | ok

What Cteno Provides

The plugin page uses shared fields to determine whether the account is connected.

Developer Usage

If the upstream CLI differs, normalize it in the wrapper.

Governance

Expired auth prompts reconnection instead of waiting for OAuth in a background task.

Policy & Safety

Safety and Governance

The open platform is not just execution. Every capability must be declarable, auditable, scoped, and disable-able.

Install Source Verification

Declaration

source, channel, sha256/signature, path traversal checks

What Cteno Provides

Daemon verifies plugin origin, version, hash/signature, and zip paths before unpacking.

Developer Usage

Publish verifiable checksums and avoid manual directory copying.

Governance

Third-party distribution needs trust prompts, signing, and allow/block policy.

Visible Permissions

Declaration

permissions.externalProcess/network/filesystem

What Cteno Provides

The plugin page shows what processes, network access, and filesystem access the plugin requests.

Developer Usage

Keep permissions narrow and explain sensitive filesystem needs.

Governance

Wrappers must not secretly enable undeclared permissions.

Execution Gating

Declaration

prompt gating + MCP gating + CLI/native gating + daemon RPC gating + GUI switch

What Cteno Provides

Registry effective state controls every execution surface.

Developer Usage

Any new surface must use the same effective state, not its own switch.

Governance

Hiding only the prompt is not disabling the plugin.

High-impact Confirmation

Declaration

Skill safety rules + permission confirmation

What Cteno Provides

Sends, approvals, deletes, payments, batch writes, and permission downgrades must enter user confirmation.

Developer Usage

Document which actions require confirmation and how to execute after confirmation.

Governance

Without explicit confirmation, produce drafts, summaries, or previews only.

Manifest Example

A plugin declares capabilities; it does not require Cteno GUI changes.

This generic CRM example declares Skill docs, a CLI wrapper, visible auth, recommendations, permissions, and distribution. A real business plugin swaps in its own id, commands, Skill, and permission scope.

{
  "schemaVersion": 1,
  "id": "acme-crm",
  "version": "0.1.0",
  "title": "Acme CRM",
  "description": "Expose CRM accounts, opportunities, notes, and approval-safe updates to Cteno Agent.",
  "defaultEnabled": false,
  "package": {
    "source": "oss",
    "channel": "stable",
    "indexUrl": "/v1/plugins/acme-crm/index"
  },
  "surfaces": {
    "prompt": {
      "fragments": ["skills/acme-crm/SKILL.md"]
    },
    "externalCli": {
      "name": "Acme CRM CLI",
      "binary": "acme-crm",
      "statusCommand": "acme-crm status --json",
      "authCommand": "acme-crm login"
    },
    "auth": {
      "command": "acme-crm login",
      "description": "Connect the CRM account in a visible terminal."
    },
    "recommendations": [
      {
        "id": "crm-daily-followups",
        "title": "Review today's customer follow-ups",
        "description": "Read open follow-ups, draft a summary, and write back after confirmation.",
        "prompt": "Use the Acme CRM plugin to prepare today's follow-ups. Ask me before writing back."
      }
    ],
    "mcp": { "servers": [] }
  },
  "permissions": {
    "externalProcess": ["acme-crm"],
    "network": true,
    "filesystem": []
  }
}

Developer Workflow

Developer Integration Flow

A Cteno plugin is closer to a small declarative platform app: the package declares capabilities, and the Host owns installation and runtime governance.

Back to Cteno Agent OS
1

Define manifest

Declare id, version, package source, surfaces, and permissions.

2

Write Skill docs

Document when to use the plugin, command schemas, boundaries, confirmations, and error handling.

3

Wrap execution

Provide a CLI wrapper, MCP server, or host/native surface with JSON-first output.

4

Declare auth/status

Expose a visible auth.command and a statusCommand with normalized connection fields.

5

Add recommendations

Turn common business workflows into one-click recommendation prompts.

6

Package and install

Publish artifacts to distribution endpoints; the daemon verifies, installs, enables, and projects them.