What are extensions?

Extensions are how you configure Daemion. They are JSON rows in SQLite — not compiled modules, not config files — validated against a Zod schema at runtime. An agent can create, update, or disable an extension mid-conversation. No deploy. No restart.

Extensions are the userspace of the Daemion kernel. The 6 substrates are the kernel. Everything else — agents, jobs, themes, commands — is an extension plugged into one or more substrates.

How many extension types are there?

There are 12 types. The agent type is the 12th — a common source of confusion when reading older docs that say 11.

Type	What it does
`command`	Slash/at/bang/hash prefix handler (`/`, `@`, `!`, `#`)
`theme`	Color scheme and font overrides for the PWA
`job`	Autonomous scheduled work unit
`renderer`	Custom display component for specialized content
`integration`	External service connection
`action`	Turn-level action button (e.g. “Copy”, “Run”)
`widget`	UI element surfaced in the app sidebar or dashboard
`app`	Vite-based app deployed through the gateway
`artifact`	Generated output artifact type
`capability`	Named capability an agent can invoke
`control`	Runtime control surface
`agent`	Persistent agent identity

Source: src/schema/extension.ts:3-16

What does an extension look like?

Every extension shares the same base schema:

json

{ “type”: “command”, “name”: “deploy”, “description”: “Run the deploy script.”, “source”: “user”, “enabled”: false, “definition”: { “prefix”: ”/”, “args”: “string”, “handler”: “deploy.sh” } }

The definition field is type-specific. command definitions require a prefix and handler. theme definitions require a colors map. app definitions require a subtype (html, chart, interactive, markdown, or fullstack). Other types use a generic key-value definition.

source tracks provenance: built-in (shipped with Daemion), user (created via API or chat), agent (created by an agent mid-conversation), or community (installed from a registry). Agent-created extensions start enabled: false — the user enables them.

How do I create extensions?

The primary path is chat. Tell Daemion what you want and it will call the API:

“Create a /standup command that summarizes what I worked on yesterday.”

The programmatic path is the REST API. See Extending Daemion for full details.

Can extensions be updated at runtime?

Yes. Extensions are rows in SQLite. Update them via PATCH /extensions/:id. Enable or disable them via POST /extensions/:id/toggle. Re-sync built-in extensions from disk without restarting via POST /reseed.

Q Can two extensions have the same name?

No — name is unique within a type. Attempting to create a duplicate returns a 409 conflict.

Q What happens when an extension has an invalid definition?

The gateway validates the definition against the type's Zod schema on create and update. An invalid definition returns a 400 with a Zod error message. The extension is never saved in a broken state.

Q Do extensions persist across gateway restarts?

Yes. They live in SQLite at ~/.daemion/daemion.db. Built-in extensions are re-seeded on startup via the reseed mechanism, but user and agent-created extensions are untouched.

Q Can agents create extensions for other agents?

Yes. An agent can POST to /extensions to create any extension type, including an agent extension that defines a new persistent identity. Agent-created extensions start disabled.

Extensions start disabled

Agent-created extensions have enabled: false by default. If a command or job you asked Daemion to create isn’t firing, check GET /extensions and enable it via POST /extensions/:id/toggle.

For the full CRUD API and type-specific definition schemas, see Extending Daemion.