1# zot extensions
2
3zot can be extended with custom slash commands by running an external
4program as a subprocess and exchanging newline-delimited JSON over
5its stdin/stdout. Extensions can be written in **any language** that
6can read and write JSON lines from stdio — Go, TypeScript, Python,
7Rust, shell with `jq`, anything.
8
9Four phases shipped so far:
10
11- **Phase 1**: slash commands + chat notifications.
12- **Phase 2**: tools the LLM can call.
13- **Phase 3**: lifecycle event subscriptions + tool-call interception
14  for guardrail extensions.
15- **Phase 4**: interactive extension-owned panels rendered inside zot.
16- **Theme-only extensions**: ship `theme.json` without launching a
17  subprocess. See [themes.md](themes.md).
18
19## Quick start
20
21The simplest extension is a script that prints a hello frame, reads
22commands, and prints responses. Here's the whole thing in **Python**,
23no SDK required:
24
25```python
26#!/usr/bin/env python3
27# $ZOT_HOME/extensions/hello-py/hello.py
28import json, sys
29
30def emit(obj):
31    sys.stdout.write(json.dumps(obj) + "\n")
32    sys.stdout.flush()
33
34emit({"type":"hello","name":"hello-py","version":"1.0.0","capabilities":["commands"]})
35
36for line in sys.stdin:
37    msg = json.loads(line)
38    if msg["type"] == "hello_ack":
39        emit({"type":"register_command","name":"hellopy","description":"say hi (python)"})
40        emit({"type":"ready"})
41    elif msg["type"] == "command_invoked":
42        emit({"type":"command_response","id":msg["id"],"action":"prompt",
43              "prompt": "Greet me very briefly in one sentence."})
44    elif msg["type"] == "shutdown":
45        emit({"type":"shutdown_ack"})
46        break
47```
48
49Drop it in a directory with this `extension.json`:
50
51```json
52{
53  "name": "hello-py",
54  "version": "1.0.0",
55  "exec": "./hello.py",
56  "language": "python",
57  "enabled": true
58}
59```
60
61`exec` is required for protocol extensions. If an extension only ships
62`theme.json` or `themes/theme.json`, no `exec` is required and zot does
63not spawn a subprocess.
64
65`chmod +x hello.py`, install:
66
67```bash
68zot ext install ./hello-py
69```
70
71Restart `zot`, type `/hellopy`, the agent greets you. Done.
72
73## Built-in extensions
74
75**zot ships with no extensions installed by default.** A fresh `zot install` (or `go install`) gives you a clean agent. Extensions are entirely opt-in: you install (or `--ext` for one run) only the ones you want.
76
77The `examples/extensions/` directory in the repo is reference code, not a default install set. To use any of those:
78
79```bash
80# go-based examples need a build first
81cd path/to/zot/examples/extensions/hello && go build -o hello .
82
83# install (copies to $ZOT_HOME/extensions/hello/)
84zot ext install path/to/zot/examples/extensions/hello
85
86# or load straight from the repo for one zot session
87zot --ext path/to/zot/examples/extensions/hello
88```
89
90Nothing is auto-installed and nothing reaches out to the network without your explicit action.
91
92## Layout & discovery
93
94zot scans two directories on startup, in this order:
95
961. **Project-local**: `./.zot/extensions/<name>/extension.json`
972. **Global**: `$ZOT_HOME/extensions/<name>/extension.json`
98
99A project-local extension with the same name wins over a global one.
100When `XDG_STATE_HOME` is set on any platform, `$ZOT_HOME` defaults to
101`$XDG_STATE_HOME/zot`. Otherwise it defaults to `~/Library/Application Support/zot/`
102on macOS, `~/.local/state/zot` on Linux, or `%LOCALAPPDATA%\zot` on Windows.
103
104Because each extension owns its own directory, the recommended place
105for extension state is inside that directory itself (for example
106`todos.json`, `settings.json`, or an auth/cache file used only by that
107extension). The host also passes this path back in `hello_ack` as
108`extension_dir` / `data_dir` so runtime code does not need to guess it.
109
110Each extension owns its own subdirectory. The `extension.json`
111manifest tells zot how to launch it:
112
113```json
114{
115  "name": "weather",
116  "version": "1.0.0",
117  "exec": "./weather",
118  "args": ["--mode", "daemon"],
119  "language": "go",
120  "description": "current weather for any city",
121  "enabled": true
122}
123```
124
125| field | meaning |
126|---|---|
127| `name` | required. how zot identifies the extension; must match what's sent in the `hello` frame. |
128| `version` | optional. shown in `zot ext list`. |
129| `exec` | required. path to the executable (relative to the manifest). |
130| `args` | optional. extra argv passed to `exec`. |
131| `language` | optional. informational only (`go`, `python`, `typescript`, ...). |
132| `description` | optional. shown in `zot ext list`. |
133| `enabled` | optional, defaults to `true`. set to `false` to disable without removing. |
134
135## Lifecycle
136
1371. **Discovery**: zot reads every `extension.json` in the search dirs.
1382. **Spawn**: enabled extensions are launched as subprocesses. stderr
139   redirects to `$ZOT_HOME/logs/ext-<name>.log` (one file per
140   extension, append-mode).
1413. **Hello handshake**: the extension's first stdout frame must be
142   `hello`; zot replies with `hello_ack` containing the protocol
143   version, the active provider/model/cwd, and the extension's own
144   data directory so it can persist files beside its manifest.
1454. **Registration**: after receiving `hello_ack`, the extension sends
146   `register_command`, `register_tool`, and subscription frames, then
147   sends `ready`. First-come-first-served: a name already taken by a
148   built-in or by a previously-loaded extension is silently shadowed
149   (logged in the extension's own log file).
1505. **Runtime**: after `ready`, zot dispatches `command_invoked` frames
151   when the user runs a registered command; the extension responds
152   with `command_response`. Extensions can also push `notify` frames
153   during runtime. Panel-capable extensions may open an interactive
154   panel, receive key events, and push redraws while the panel is
155   focused.
1566. **Shutdown**: when zot exits, it sends `shutdown` and waits up to
157   2s for the extension to send `shutdown_ack`. Holdouts are
158   SIGTERM'd, then SIGKILL'd.
159
160A crashing extension does not bring down zot. The slash command it
161owned simply stops working until the extension is fixed and zot is
162restarted.
163
164## Wire format
165
166All frames are one JSON object per line. Top-level `type` is the
167discriminator. Optional `id` correlates request frames with their
168responses. The canonical startup order is `hello`, `hello_ack`,
169registration frames, then `ready`. Do not send `notify`, logs, or any
170other stdout frame before `hello`.
171
172### Extension → host
173
174#### `hello` (required, first frame)
175
176```json
177{"type":"hello","name":"weather","version":"1.0.0",
178 "capabilities":["commands","tools","panels"]}
179```
180
181#### `register_command`
182
183```json
184{"type":"register_command","name":"weather",
185 "description":"current weather for a city"}
186```
187
188Command names are matched case-insensitively. zot sends `command_invoked.name` using the canonical spelling registered here. Registrations that differ only by case conflict, and the first registration remains active.
189
190#### `register_tool`
191
192Registers a tool the LLM can call. `schema` is a JSON Schema object
193describing the tool's args (the same shape Anthropic and OpenAI accept).
194
195```json
196{"type":"register_tool","name":"weather",
197 "description":"Get the current weather for a city.",
198 "schema":{
199   "type":"object",
200   "properties":{"city":{"type":"string"}},
201   "required":["city"]
202 }}
203```
204
205Tool names live in the same namespace as built-in tools (`read`,
206`write`, `edit`, `bash`, `skill`). Conflicts are silently shadowed by
207the built-in.
208
209Set `"deferred": true` to register a tool without advertising its definition initially. A loader tool can activate registered deferred tools by returning their names in `activate_tools`:
210
211```json
212{"type":"tool_result","id":"...",
213 "content":[{"type":"text","text":"Enabled weather lookup"}],
214 "activate_tools":["weather"]}
215```
216
217On Kimi K3's OpenAI-compatible routes, zot places newly activated schemas at the tool-result position using Kimi's native deferred-tool format. Other models receive the complete active tool list on the next request. Unknown names are ignored. The Go extension SDK exposes `DeferredTool` and `ToolResult.ActivateTools` for the same protocol.
218
219#### `ready`
220
221Sentinel telling zot "all initial registrations are flushed". Send it
222right after your last `register_*` frame so the host can build the
223agent's tool registry without racing the registration window.
224
225```json
226{"type":"ready"}
227```
228
229#### `tool_result`
230
231Reply to a `tool_call` from the host. `content[]` is a list of
232message blocks; each block is `{"type":"text","text":"..."}` or
233`{"type":"image","mime_type":"image/png","data":"<base64>"}`. Set
234`is_error: true` to mark the call as failed. `activate_tools` can name
235registered deferred tools that become available after this result.
236
237```json
238{"type":"tool_result","id":"...",
239 "content":[{"type":"text","text":"Berlin: 16°C, fog"}]}
240```
241
242#### `subscribe`
243
244Declares which lifecycle events the extension wants to observe and
245which it wants to intercept. Send once after `hello`, before `ready`.
246
247```json
248{"type":"subscribe",
249 "events":["session_start","turn_start","tool_call","turn_end","assistant_message"],
250 "intercept":["tool_call","turn_start","assistant_message"]}
251```
252
253Recognised event names: `session_start`, `turn_start`, `turn_end`,
254`tool_call`, `assistant_message`.
255
256Interceptable events:
257
258- `tool_call`: block the call (model sees `reason` as the tool
259  error) or rewrite args via `modified_args`.
260- `turn_start`: block the turn before the model is called. Useful
261  for rate-limiting and business-hour gates. `reason` is shown to
262  the user as a status line. No rewrite supported.
263- `assistant_message`: suppress the message via `block`, or rewrite
264  the user-visible text via `replace_text`. The model's original
265  text stays in the transcript so the model sees what it actually
266  said on subsequent turns.
267
268#### `event_intercept_response`
269
270Reply to an `event_intercept` from the host. All fields default to
271"allow, pass through unmodified".
272
273| field | meaning |
274|---|---|
275| `block` | `true` refuses the action. For `tool_call`, `reason` is shown to the model; for `turn_start` / `assistant_message`, `reason` is shown to the user. |
276| `reason` | refusal text (on block) or pass-through note. |
277| `modified_args` | for `tool_call`: rewritten JSON args the tool will actually see. Must be a valid JSON object. Ignored when `block` is true. |
278| `replace_text` | for `assistant_message`: replaces the user-visible text. The model's original output still lives in the transcript. Ignored when `block` is true. |
279
280Missing the response within 5s is treated as "allow" (i.e. an
281unresponsive extension never stalls the agent). When multiple
282extensions subscribe to the same event, they're consulted serially;
283the first `block` wins and rewrites (args / text) chain: each
284subsequent interceptor sees the previous one's output.
285
286```json
287{"type":"event_intercept_response","id":"...",
288 "block":true,"reason":"refused: matches danger pattern \"rm -rf\""}
289
290{"type":"event_intercept_response","id":"...",
291 "modified_args":{"command":"echo GUARDED: ls"}}
292
293{"type":"event_intercept_response","id":"...",
294 "replace_text":"[redacted]"}
295```
296
297#### `command_response` (reply to `command_invoked`)
298
299```json
300{"type":"command_response","id":"...","action":"prompt",
301 "prompt":"Show today's weather for Berlin in one line."}
302```
303
304`action` is one of:
305
306- `"prompt"` — submits `prompt` as a fresh user message; the agent
307  runs a turn against it.
308- `"insert"` — inserts `insert` into the editor at the cursor without
309  submitting.
310- `"display"` — appends `display` to the chat as a one-shot styled
311  note. No model call, nothing written to the transcript.
312- `"open_panel"` — opens an extension-owned interactive panel inside
313  zot. The panel content lives in `open_panel`.
314- `"noop"` — the extension handled it itself (e.g. it pushed
315  `notify` frames or kicked off background work). zot doesn't change
316  the UI in response.
317
318Example:
319
320```json
321{"type":"command_response","id":"...","action":"open_panel",
322 "open_panel":{
323   "id":"todos-main",
324   "title":"Todos",
325   "lines":["□ ship panel api","✓ persist state"],
326   "footer":"↑/↓ navigate - a add - x complete - esc close"
327 }}
328```
329
330If `error` is non-empty, zot renders it as a red status line
331regardless of `action`.
332
333#### `submit` (one-way, any time)
334
335Submits text as a user prompt in the interactive host. If the agent is
336idle, zot starts a turn immediately. If a turn is already running, zot
337queues the prompt behind it using the same queue path as typed input.
338Empty or whitespace-only text is ignored.
339
340```json
341{"type":"submit","text":"Summarize the selected workspace."}
342```
343
344In print / JSON / RPC modes this frame is ignored because there is no
345interactive editor or prompt queue.
346
347#### `panel_render` (one-way, while a panel is open)
348
349Pushes a fresh frame for an already-open panel.
350
351```json
352{"type":"panel_render","panel_id":"todos-main",
353 "title":"Todos",
354 "lines":["□ ship panel api","✓ persist state"],
355 "footer":"↑/↓ navigate - a add - x complete - esc close"}
356```
357
358#### `panel_close`
359
360Closes a previously-open panel.
361
362```json
363{"type":"panel_close","panel_id":"todos-main"}
364```
365
366#### `notify` (one-way, any time)
367
368```json
369{"type":"notify","level":"info",
370 "message":"refreshed cache (12 entries)"}
371```
372
373`level` is one of `info`, `success`, `warn`, `error`. The note shows
374up below the transcript with the extension's name in brackets. Notes
375are one-shot: they clear automatically when the user sends their next
376prompt (and on `esc` / `/clear`).
377
378#### `clear_notes` (one-way, any time)
379
380Removes every note this extension previously pushed via `notify` /
381`display`. Use it for transient status lines (e.g. an approval prompt)
382so they do not stack up; notes from other extensions are untouched.
383
384```json
385{"type":"clear_notes"}
386```
387
388In `--mode rpc`, this surfaces to the host as an `ext_clear_notes`
389event (alongside `ext_notify` / `ext_display`).
390
391#### `shutdown_ack`
392
393Sent in response to `shutdown`. Extension should exit promptly after.
394
395### Host → extension
396
397#### `hello_ack`
398
399```json
400{"type":"hello_ack","protocol_version":1,
401 "zot_version":"0.0.7","provider":"anthropic",
402 "model":"claude-opus-4-7","cwd":"/Users/pat/Developer/zot",
403 "extension_dir":"/Users/pat/Developer/zot/.zot/extensions/todos",
404 "data_dir":"/Users/pat/Developer/zot/.zot/extensions/todos"}
405```
406
407Sent immediately after `hello`. Wait for this frame before sending
408registrations if they depend on host metadata. The extension can use
409these fields to decide which commands to register (e.g. only register
410a Python tool on macOS, only register a model-specific shortcut for
411opus, etc.). `cwd` is the user's project directory; the extension
412process itself runs from the extension directory, so do not use
413`os.Getwd()` or `process.cwd()` when you need the project path.
414`extension_dir` / `data_dir` are where the extension should persist
415its own state (for example `todos.json`, cached metadata, or auth
416tokens scoped to that extension).
417
418#### `command_invoked`
419
420```json
421{"type":"command_invoked","id":"...",
422 "name":"weather","args":"berlin"}
423```
424
425`args` is everything the user typed after the command name, trimmed.
426
427#### `tool_call`
428
429Sent when the LLM invokes a tool the extension registered. `args` is
430the parsed JSON object the model produced; the extension is
431responsible for validating/coercing it.
432
433```json
434{"type":"tool_call","id":"...","name":"weather",
435 "args":{"city":"Berlin"}}
436```
437
438Reply with `tool_result` within the host's tool timeout (default 60s).
439Missing the timeout surfaces an error to the model and the call is
440marked as failed.
441
442#### `event`
443
444Lifecycle notification for events the extension subscribed to via
445`subscribe`. One-way — no response expected.
446
447```json
448{"type":"event","event":"turn_start","step":1}
449{"type":"event","event":"tool_call",
450 "tool_id":"...","tool_name":"read","tool_args":{"path":"foo.go"}}
451{"type":"event","event":"turn_end","stop":"end_turn"}
452```
453
454#### `event_intercept`
455
456Sent when zot wants to give the extension a chance to block, modify,
457or annotate a lifecycle event before it happens. Reply with
458`event_intercept_response` within 5s; missing the deadline is
459treated as "allow".
460
461Payload fields depend on the event:
462
463```json
464// tool_call: includes the tool id, name, and parsed args
465{"type":"event_intercept","id":"...","event":"tool_call",
466 "tool_id":"...","tool_name":"bash",
467 "tool_args":{"command":"rm -rf /tmp/foo"}}
468
469// turn_start: includes the step number
470{"type":"event_intercept","id":"...","event":"turn_start",
471 "step":3}
472
473// assistant_message: includes the assembled text
474{"type":"event_intercept","id":"...","event":"assistant_message",
475 "text":"here is your api key: sk-ant-..."}
476```
477
478#### `panel_key`
479
480Sent while an extension-owned panel is focused. `key` is a normalized
481name (`up`, `down`, `left`, `right`, `enter`, `esc`, `tab`, `pageup`,
482`pagedown`, `home`, `end`, `backspace`, `delete`, `rune`). For
483`key:"rune"`, `text` carries the typed character.
484
485```json
486{"type":"panel_key","panel_id":"todos-main","key":"down"}
487{"type":"panel_key","panel_id":"todos-main","key":"rune","text":"x"}
488```
489
490#### `panel_close`
491
492Sent when the user closes the focused panel from zot (for example with
493Esc or Ctrl+C). The extension should treat this as the panel lifetime
494ending and stop sending `panel_render` updates for that `panel_id`.
495
496```json
497{"type":"panel_close","panel_id":"todos-main"}
498```
499
500#### `shutdown`
501
502Sent during graceful zot exit (or `/reload-ext` once that lands).
503Reply with `shutdown_ack` and then exit.
504
505## Managing extensions from the CLI
506
507```
508zot ext list                    list installed extensions and their state
509zot ext doctor                  diagnose load, registration, and conflict issues
510zot ext install <path|git-url>  copy / clone into $ZOT_HOME/extensions/
511zot ext remove <name>           delete an extension directory
512zot ext enable <name>           re-enable a disabled extension
513zot ext disable <name>          disable without removing
514zot ext logs <name> [-f]        cat / tail the extension's stderr
515```
516
517`zot ext doctor` runs the same discovery path as zot startup, but reports
518what happened instead of changing the fail-soft runtime behavior. It shows
519manifest errors, disabled or shadowed extensions, subprocess load errors,
520ready/auto-ready status, registered commands/tools, registration conflicts,
521warnings, and each extension's stderr log path.
522
523`zot ext install <path>` does a recursive copy; `<git-url>` does a
524shallow clone. Both validate that the destination contains an
525`extension.json` and roll back if not.
526
527## Loading an extension for one run
528
529For iteration on a working copy, skip the install + reload cycle
530and load straight from disk for one zot session:
531
532```
533zot --ext ./my-extension        # short form: -e ./my-extension
534zot --ext ./a -e ./b            # repeatable
535```
536
537`--ext` paths take precedence over installed extensions of the same
538name, so you can shadow an installed copy with a work-in-progress
539version without uninstalling first. Nothing is copied or persisted;
540the extension dies with zot like any other subprocess.
541
542## SDKs
543
544Writing the wire protocol by hand is fine for one-off scripts, but
545for anything bigger the SDKs handle the boilerplate.
546
547### Go — `packages/agent/ext`
548
549```go
550package main
551
552import (
553    "encoding/json"
554    "github.com/patriceckhart/zot/packages/agent/ext"
555)
556
557func main() {
558    e := ext.New("hello", "1.0.0")
559
560    // Slash command
561    e.Command("hello", "say hi", func(args string) ext.Response {
562        return ext.Prompt("Greet me in one short sentence.")
563    })
564
565    // LLM-callable tool
566    e.Tool("weather", "Current weather for a city.",
567        json.RawMessage(`{"type":"object","properties":{"city":{"type":"string"}},"required":["city"]}`),
568        func(args json.RawMessage) ext.ToolResult {
569            var in struct{ City string `json:"city"` }
570            json.Unmarshal(args, &in)
571            return ext.TextResult(in.City + ": sunny")
572        })
573
574    // Optional: register project-specific commands after hello_ack.
575    e.OnHello(func(host ext.HostInfo) {
576        if host.CWD != "" {
577            e.Command("cwd", "show the current project directory", func(args string) ext.Response {
578                return ext.Display(host.CWD)
579            })
580        }
581    })
582
583    e.Run()
584}
585```
586
587Build with `go build -o hello .`, drop the binary + an `extension.json`
588into `$ZOT_HOME/extensions/hello/`.
589
590`OnHello` is optional. Use it when configuration or registrations need
591host metadata such as `HostInfo.CWD`, `Provider`, `Model`, `ZotVersion`,
592`ExtensionDir`, or `DataDir`. The SDK sends `hello`, waits for
593`hello_ack`, runs `OnHello`, announces registrations, then sends `ready`.
594
595The SDK has four interceptor hooks, all optional:
596
597```go
598// e is the *ext.Extension returned by ext.New(...).
599
600// Refuse calls or rewrite args before they run.
601e.InterceptToolCall(func(tool string, args json.RawMessage) (bool, string) {
602    if tool == "bash" { /* inspect args, return false, reason */ }
603    return true, ""
604})
605
606// Richer variant: returns ToolCallDecision so you can also rewrite
607// args via ModifiedArgs.
608e.InterceptToolCallX(func(tool string, args json.RawMessage) ext.ToolCallDecision {
609    return ext.ToolCallDecision{
610        ModifiedArgs: json.RawMessage(`{"command":"echo GUARDED"}`),
611    }
612})
613
614// Block the next turn before the model is called.
615e.InterceptTurnStart(func(step int) ext.TurnStartDecision {
616    if time.Now().Hour() < 9 { return ext.TurnStartDecision{Block: true, Reason: "outside business hours"} }
617    return ext.TurnStartDecision{}
618})
619
620// Scrub or rewrite the assistant's final text before the user sees it.
621e.InterceptAssistantMessage(func(text string) ext.AssistantMessageDecision {
622    return ext.AssistantMessageDecision{
623        ReplaceText: strings.ReplaceAll(text, "SECRET", "[redacted]"),
624    }
625})
626```
627
628See:
629- `examples/extensions/hello/` — slash commands
630- `examples/extensions/clock/` — slash commands in plain Node, no SDK
631- `examples/extensions/weather/` — LLM-callable tool
632- `examples/extensions/guard/` — event subscriptions + tool-call
633  interception (refuses dangerous bash patterns)
634- `examples/extensions/todo/` — interactive persistent panel + tool
635- `examples/extensions/scratchpad/` — source-run TypeScript commands + tool
636
637### Hot reload
638
639Type `/reload-ext` in the TUI to tear down every running extension
640subprocess, re-read the manifests from disk, and respawn the set.
641The agent's tool registry is rebuilt automatically, so freshly-
642registered extension tools become callable without restarting zot.
643Useful while developing an extension: edit, save, `/reload-ext`,
644done. Explicit `--ext` paths are remembered and reloaded alongside
645discovered extensions. The temporary reload status reports each load
646error in red, including its message, and dismisses itself after five
647seconds.
648
649### TypeScript / Python
650
651These SDKs aren't in the main repo yet; the wire format is small
652enough that a `~30 line` raw script gets you started in either
653language. See the [Quick start](#quick-start) Python example for the
654shape. SDK packages will land in follow-up commits.
655
656## Security
657
658Extensions run with **the user's full filesystem and network
659permissions**. Treat installing an extension the same as installing
660any other binary on your machine.
661
662`zot ext install <git-url>` clones from any URL you give it. There's
663no sandbox in v1; if you need isolation, install only extensions you
664trust or run zot under your platform's sandboxing tool (`bwrap` /
665`sandbox-exec` / AppContainer).
666
667## Roadmap
668
669Phase 1 (shipped):
670- [x] subprocess lifecycle + hello handshake
671- [x] `register_command` + `command_invoked`
672- [x] `notify` + `clear_notes`
673- [x] `zot ext` CLI
674
675Phase 2 (shipped):
676- [x] `register_tool` + `tool_call` + `tool_result`
677- [x] `ready` sentinel for safe agent-registry build timing
678- [x] tool result attribution surfaces extension name in details
679
680Phase 3 (shipped):
681- [x] event subscriptions (`session_start`, `turn_start`, `turn_end`,
682      `tool_call`, `assistant_message`)
683- [x] tool-call interception (block before execution)
684
685Phase 4 (shipped):
686- [x] interception for `turn_start` and `assistant_message` (in
687      addition to `tool_call`)
688- [x] modify tool args mid-flight via `modified_args`
689- [x] rewrite user-visible assistant text via `replace_text`
690- [x] `/reload-ext` slash command (hot-reload without restarting zot)
691
692Future (no firm timeline):
693- [ ] TypeScript and Python SDK packages (currently the wire format
694      is stable enough to hand-roll, see the Python quick-start)
695- [ ] HTTP / WebSocket transport variants (today: subprocess stdio)
696- [ ] per-extension permission scopes (today: full user privileges)