Roadmap & API status
The whole platform Silo is building toward — and what's real today. This page is the source of truth for what you can build on now vs. what's still being designed. As a primitive ships, its badge flips from
planned to stable.The goal: a small, stable core, after which most new features are extensions built on these primitives — first-party and third-party alike. When the core table below is all green, we've hit that inflection point.
Legend: stable available now ·
experimental usable, may change ·planned designed, not yet implementedCore (ctx) primitives
| Primitive | Status | |
|---|---|---|
Registration (register*) | stable | docs |
executeCommand | stable | docs |
ctx.workspaces | stable | docs |
ctx.layout | stable | docs |
ctx.process (persistent sessions) | stable | docs |
ctx.process.exec (one-shot subprocess) | stable | docs |
Terminal environment (SILO_* identity, spawn env) | stable | docs |
ctx.processes (foreground process observer) | stable | docs |
ctx.agents (coding-agent activity + resume hints) | beta | How it works — keyed on the Agent Session (Terminal or Chat), one AgentInfo shape for both, including a host-computed title; reveal / resume / close verbs, getActive / subscribeActive, and bindActivity / bindIcon keyed on the session so one provider badges a terminal tab and a Chat transcript tab alike (RFC 0038) |
ctx.agents.catalog() (+ AgentIconGlyph) | beta | docs · RFC 0033 |
Agent Profiles (ctx.agents.profiles) | beta | docs · RFC 0033 — list() + launch({ prompt }); an opening prompt is delivered as a literal or refused, never mangled |
Chat sessions (ctx.agents.sessions) | beta | docs · RFC 0038 — connect() a user-authored Chat profile (an Agent Client Protocol child) and prompt / cancel / watch it; needs the "agents" permission. The update stream models what a transcript must draw — toolCall (id, title, kind, status, content, locations) and the whole plan — so raw is an escape hatch, not the way to render one. connect({ resume }) reconnects a persisted session over session/resume / session/load, falling back to the transcript journal (RFC 0042 Phase 1); a session in a workspace you haven't opened yet is still listed, as chatResumeState: "dormant", and connects when you reveal it |
Extension-API mechanism (getExtension) | stable | docs |
ctx.editors (documents) | stable | docs |
ctx.terminals (terminal tabs) | stable | docs |
Tab adornments (editors / terminals setIcon / setIndicator / setActivity / …) | stable | docs · ADR 0029 · ADR 0030 |
Activity chrome (Activity kind + SDK ActivityGlyph) | stable | ADR 0030 · workspace status + tab adornments |
ctx.terminals.registerTabDecoration (deprecated shim) | stable | docs — prefer bindIndicator / bindActivity |
| Side-panel tab adornments (owner handle) | planned | RFC 0022 |
Recorded dock panels (DockPanelKind.persistence + Workspace.panels) | experimental | docs · RFC 0041 — a DockPanelKind that declares persistence: "recorded" gets a DockPanelRecord per open panel, reopened on restart like an editor/terminal tab; t.workspaceId on the "panel" toolbar target. RFC 0046 adds a generic "panel/tab" context-menu surface (every panel tab, any kind) and DockPanelKind.renamable (DockPanelRecord.customTitle, host-owned and restart-durable). Enumeration + tab adornments (ctx.panels) are a later phase |
DockPanelProps.onScreen | stable | docs — host-resolved "the user can see this panel" (tab selected and workspace active). A dock panel is never remounted for going off screen, so DOM measurement and restore belong on this flag, not on mount |
ctx.registerToolbarItem | stable | docs · RFC 0021 |
ctx.terminals.focus | stable | docs |
ctx.terminals.subscribeOsc | stable | docs |
ctx.terminals.getActive / subscribeActive | stable | docs |
ctx.terminals.subscribeOutput | stable | docs |
includeReplay on subscribeOutput / subscribeOsc / onData | stable | docs — opt in to the scrollback replayed on re-attach, tagged so it isn't read as live activity |
ctx.workspaces status / badges (set / clear / bind) | stable | docs · adorn verbs; registerStatus / registerBadge deprecated shims |
ctx.workspaces.registerSection | stable | docs |
ctx.registerNavigatorView (Navigator panel views) | stable | docs · RFC 0023 |
ctx.workspaces.getOpenWorkspaceMenuItems | stable | docs |
ctx.workspaces.getWorkspaceMenuItems | stable | docs |
ctx.terminals.getTabMenuItems | stable | docs |
ctx.files | stable | docs |
ctx.theme + ctx.theme.registerPreset | stable | docs |
ctx.dnd (drag-and-drop) | stable | docs |
useServiceState (reactive reads) | stable | docs |
useFocusGroup (keyboard nav for a group) | stable | docs |
Tooltip (styled hover popup) | stable | docs |
| Design-system components (modal kit) | stable | docs · RFC 0016 |
--silo-list-* tokens + .silo-scroll | stable | docs |
ctx.ui (pickers + notify w/ actions + menus) | stable | docs |
ctx.ui (confirm / prompt) | stable | docs |
ctx.ui.showModal (custom modal content) | stable | docs |
ctx.layout.openPanelSheet (dock sheet anchored to a side panel) | stable | docs · RFC 0029 |
ctx.ui.confirmWithDontShowAgain | stable | docs · RFC 0029 |
ctx.ui.openExternal (open a URL out) | stable | docs |
ctx.ui.getActiveSelectionText | stable | docs |
ctx.net (server-side HTTP, bypasses CORS) | stable | docs |
ctx.system (OS, arch, Silo version) | stable | docs |
ctx.system.homeDir | stable | docs · RFC 0029 |
ctx.search (cross-file content search) | stable | docs |
ctx.search (replace-in-files) | planned | design |
ctx.ui (quickPick / progress) | planned | design |
ctx events (typed Event<T>) | stable | docs |
ctx.editors.getState / subscribe | stable | docs |
path (cross-platform path utilities) | stable | docs |
| per-extension settings (page + persistence) | stable | docs |
ctx.storage (global / workspace) | stable | docs |
ctx.storage directories (globalDir / workspaceDir / workspaceDirs) | stable | docs |
ctx.secrets (host-mediated credentials) | planned | RFC 0004 |
ctx.webview (cross-origin iframe bridge) | stable | docs |
| context-menu contributions (workspace, terminal/link, editor/tab, terminal/tab) | stable | docs |
| context-menu contributions (explorer/item) | planned | design |
ctx.workspaces.registerPropertyPage | stable | docs |
Extension-owned features
Features that ship built-in but are implemented as extensions on the primitives above — so a third party could build the same.
| Feature | Status | Built on | Publishes |
|---|---|---|---|
| Git | stable | process.exec + files + workspaces | GitAPI (@silo-code/git-api) — one-shot reads/mutations plus a live watchRepo session (ADR 0037) |
| Markdown Preview | stable | registerEditor + files | — |
| Terminal | stable | process sessions + dock panel | — |
| Agent Chat panel | beta | agents.sessions + dock panel | silo.agents-chat-panel — bundled (disable-only, like any silo.* extension); built on ctx.agents.sessions + the public SDK alone (DockPanelKind.toolbar / setBreadcrumb, the "panel" toolbar surface — trusted built-ins are exempt from declaring the "agents" permission a third-party Chat UI still needs), so it is the proof a third-party Chat UI is fully expressible (RFC 0038 · RFC 0039) |
| Theme management | stable | theme + files + ui | — |
| Search (find-in-files) | stable | search + editors | — |
Each ships as a real extension package (
core.*/silo.*) that touches the app only throughctx— the same surface a third party gets. The core primitives they lean on (the terminal'sprocesssessions, the theme domain service) still live in the host; that split is by design. The decisions behind the model are recorded as ADRs indocs/decisions/.This table is bundled features only. Extensions that live in
silo-code/silo-extensionsand are installed at runtime —silo.follow-ups,silo.agent-monitor, andsilo.tasks(RFC 0031) — deliberately get no row here; they are discovered through Browse, not shipped in the app.
Extension distribution
How a third-party extension gets from a package into the running app. See Extensions (install / Browse / updates) and Publishing an extension.
| Capability | Status | |
|---|---|---|
Author against @silo-code/sdk from npm | stable | docs |
| Install from local folder | stable | docs |
| Enable / disable / uninstall (runtime) | stable | docs |
| First-party built-ins listed (disable-only, branded) | stable | docs |
| Load on launch + persisted registry | stable | docs |
silo install / silo uninstall CLI | stable | docs |
npx create-silo-extension scaffold | stable | docs |
| Install from URL (tarball / GitHub release) | stable | docs |
| Install from npm registry | stable | docs |
| Update checking + apply | stable | docs |
| Extension registry — browse / search / install | stable | docs · catalog |
Registry website (extensions.getsilo.dev) | stable | extensions.getsilo.dev |
| Private / team registries (federated index) | planned | design |
| Permissions / capability model | stable | docs |
Updates: "Update checking + apply" is the P1 registry feature — the app polls registry.getsilo.dev, shows a badge, and applies Update / Update all from Settings → Extensions. That is not the same as Safe update below (stage → validate → swap + rollback on a bad install), which is still planned.
Extension model & safety
The contract + lifecycle work that makes the system survivable at scale. The designed pieces are RFCs in docs/proposals/ (esp. 0005 / 0006); the rest is tracked in the table above.
| Capability | Status |
|---|---|
Manifest id / path validation | stable |
Declarative contributes + activation events | planned |
engine compatibility enforcement | planned |
| Sandbox / capability gating (untrusted code) | planned |
| Storage cleanup on uninstall | planned |
| Safe update (stage-validate-swap + rollback) | planned |
| Failed-load error surfacing + collision reporting | planned |
Designed surfaces (planned)
The shape of each planned surface is now designed in an RFC under docs/proposals/ (subject to change until it ships):
| Planned surface | RFC |
|---|---|
ctx.ui slice 2 — quickPick / progress (prompt covers inputBox) | RFC 0001 |
ctx.secrets — host-mediated credentials (storage global / workspace shipped) | RFC 0004 |
Declarative contributes + activation events | RFC 0005 |
| Sandboxed extension execution (the permission model itself is stable) | RFC 0006 |
Extension CSS auto-injection + SDK createStore | RFC 0007 |
Language intelligence (TS/JS via tsserver) — held, not scheduled | RFC 0009 |
Context-menu contributions — explorer/item dispatch | RFC 0013 |
| pty-host daemon relocated outside the AppImage mount (Linux) | RFC 0017 |
Hooks as an authoritative agent-activity channel (blocked state, sub-agents) | RFC 0020 |
Side-panel tab adornments (owner handle from registerSidePanel) | RFC 0022 |
| Git-detection handler claim protocol | RFC 0024 |
Extension-to-extension version floors (engine-style, generalized) | RFC 0025 |
| Private / team registries (federated index) | RFC 0014 |
RFCs 0002 (typed
ctxevents), 0008 (package format + remote install) and 0014 (the registry) used to sit in this table and have since shipped — they areimplementednow, and only the leftovers listed above are still open.
Tooling
Not part of the extension SDK — host-side developer/test surfaces.
| Surface | Status | |
|---|---|---|
silo <path> CLI | stable | docs |
| CLI noun grammar | planned | ADR 0047 |
| CLI Control API | planned | RFC 0034 |
| Automation RPC (dev) | experimental | design |
| Nightly release channel | stable | docs |
silo <path> CLI stable
A terminal entry point: silo <dir> foregrounds (or launches) Silo and opens/activates a workspace for that folder; silo <file> opens the file in the active workspace; silo agent run [--profile <id>] launches an Agent Profile (RFC 0033) into the workspace the shell is in. Built on tauri-plugin-single-instance — a second launch is forwarded to the running instance rather than opening a new window. Commands that report a result (status, ws list, agent run) go through the Control API below instead. Install the command from File → Install silo Command in PATH. See the silo command.
CLI noun grammar planned
Every silo capability gets one canonical spelling, silo <noun> <verb>, with today's forms kept as permanent shorthands: silo <path> for silo ws open, silo install for silo ext install. Reserved nouns are ext, ws, agent, term, and help — a folder with one of those names is still reachable as ./ws or silo -- ws. Machine callers get --json, a --ws <folder|.|id> flag on workspace-scoped verbs, and commands that never prompt, because the CLI's primary consumer is a coding agent. Also lands the targeting fix: a path inside a workspace resolves to that workspace — so silo README.md stops opening in whichever workspace the app last focused, and silo . from a subdirectory switches to the project above it instead of creating a second workspace.
CLI Control API stable
A return channel, so a silo command can answer: real stdout, a real exit code, and one --json envelope. The CLI used to be a one-way forwarder — argv in, exit 0 out — which is fine for "open this folder" and useless for "which workspaces exist" or "what id did that get".
silo status reports whether Silo is running and whether it is actually serving commands (so a wedged app looks different from no app). silo ws list reads your workspace files from disk — it works with Silo closed — and annotates each row with live state when Silo is up. silo agent run now returns the id of the terminal it created. Every one takes --json for one parseable line, and every one exits with a code you can branch on. --launch starts Silo and waits for it when nothing is running.
The channel is a per-user Unix socket (Windows: a named pipe) that only processes running as you can reach — no port, nothing a web page can touch — and it accepts a closed list of named operations rather than anything the app can do. Extensions don't reach it; they have ctx. Separate from the dev-only Automation RPC below. See the silo command.
Automation RPC experimental
A dev-only loopback HTTP RPC for driving the real running app from a test suite, CI, or an agent — works around macOS having no WKWebView automation hook. Excluded from release builds (Cargo automation feature + frontend DEV guard); in dev it's always on but every request must carry an X-Silo-Automation header and a loopback Host, so a web page you visit can't drive it. Ops include ping, exec (run a registered command), activeElement / editorsDetail (focus introspection), workspace/file test-driver ops, contextKeys, and eval. See docs/automation.md.