v0.25.0

Extensions can use remote services, and agents suggest the extensions their people need. The documentation is now in Spanish too, under /es/.

New features

• Remote MCP servers (#61). An installed extension's .mcp.json may declare type: "http" (or "sse") servers with a url and headers: nothing runs on the computer, its options (${user_config.KEY}) and the agent's variables are filled in when the session opens, and the address must be https (http only on localhost). Each gets a session name of its own, <extension>-<server>, so it never signs in with the runner's own Claude Code tokens. See A remote server.
• Signing in from the chats. A remote server behind OAuth shows as needing sign-in in /extensions; /extensions sign-in <name> (the chat controller's signInExtension()) gives the person the link and says when it's done, a callback address pasted from another computer finishes it, and /extensions sign-out <name> clears it. It uses the SDK's sign-in methods, which aren't in its typings yet: the kit calls them only when they exist (ADR-028).
• Installing, extension info, the catalog and catalog.json (remote) name the hosts an extension talks to.
• The agent as an advisor on extensions (#64). With awareness and a folder for extensions, the agent has extensions_catalog (read-only): what's installed and how it stands, what its catalogs offer (from their copies, filtered by catalogTopics), and with refresh what's new online. Asked for something its tools don't do well, it suggests a fitting extension in one sentence and goes on without it; it never installs one itself. An extensions skill helps with installed ones, their options and why one is off. See The agent's own suggestions.
• The documentation in Spanish: every guide, the homepage and the site's interface, with a language selector; the API reference stays English.
• New exports: isRemoteServer(), remoteHosts(), remoteServerName(), LocalServer, RemoteServer, ExtensionAuth, SignIn, McpAuthentication; buildSessionOptions() returns extensionAuth; extensionCatalog() takes a language.
• @falkenslab/agent-kit-catalog 0.4.0 writes remote into catalog.json.

Fixes

• The docs name the marketplace's new repository, falkenslab/agent-extensions.
• The site's footer is Falken's Lab's signature alone.

Breaking changes

• PluginServer is LocalServer | RemoteServer: code that reads a server's command checks isRemoteServer() first.
• addExtension(), installFromMarketplace() and installExtension() also return remote (the hosts); CatalogEntry has remote.
• A remote extension's changed option opens the session again (restartExtension() returns false for it): the SDK fixes a remote server's URL and headers when the session opens.

Captain Whiskers

Captain Whiskers 0.6.0, the example agent built on agent-kit 0.25.0, as a Windows app: download the installer. It's unsigned, so SmartScreen warns about it; it asks for a Claude key on first start and keeps everything in ~/.captain-whiskers. New: he suggests an extension of his shipyard when you ask for what it does, and his drawer says which service an extension talks to.

v0.24.0

Extensions speak the person's language: their descriptions and READMEs per language reach the chats' catalog, extension info and a marketplace's catalog.json. See Writing one.

New features

• Descriptions and READMEs per language (#67). metadata["agent-kit"].description gives an extension's description in es, fr and de; English stays plugin.json's own description, which Claude Code reads (and so does the model: the prompt keeps English). The chats' catalog (/extensions search, the chat controller's CatalogEntry.description, Captain Whiskers' drawer) and extension info show it in the session's language, English as fallback, and the catalog's search matches it. extension info points to README.<lang>.md when there is one.
• @falkenslab/agent-kit-catalog 0.3.0 writes descriptions and readmes per language into catalog.json when an extension has other than English, and checks metadata["agent-kit"].description; both schemas describe them.

Fixes

• The extensions tutorial's links to agent-kit-extensions follow its extensions/ folder and moodle-teacher (they 404'd), in the 0.22.0 and 0.23.0 docs too.

Breaking changes

• ExternalManifest has descriptions, and CatalogEntry has description (in the kit's language): a host building either by hand adds them.

Captain Whiskers

Captain Whiskers 0.5.0, the example agent built on agent-kit 0.24.0, as a Windows app: download the installer. It's unsigned, so SmartScreen warns about it; it asks for a Claude key on first start and keeps everything in ~/.captain-whiskers. New: his drawer shows each extension's description in his language, and his jokebook (1.3.1) has it in the kit's four; an installed jokebook shows the update.

v0.23.0

Extensions now say what they let an agent do, and what they need on the computer. See Extensions and Programs it needs.

New features

• Capabilities described for the person (#62). metadata["agent-kit"].capabilities lists what the agent can do with an extension: each one's skills and tools together, with a label and description per language. /extensions, about_me, extension info and the catalog show them (the chat controller's entries, Captain Whiskers' drawer, a marketplace's catalog.json), and the catalog's search matches them. A capability's id counts as provided, so requires gates on it as before; give it a neutral id (lms-grading) so skills depend on what can be done, not on which extension does it. Installing refuses a capability naming a skill the extension lacks; /extensions says when a capability's tool isn't offered by its running server.
• The programs an extension needs (#63). metadata["agent-kit"].requirements declares programs the person installs (Docker, ffmpeg…): how to check the version, how to install it per system, and the capabilities that need it. The kit checks them when a session opens (a bare name on the PATH, run only with option arguments, no shell, a timeout) and never installs them. One the whole extension needs keeps it off with the install command for this system; one only some capabilities need keeps just those off (not provided, their skills left out), and the agent says what to install. extension add, /extensions install and the chat controller say what's missing; the catalog shows "Needs Docker".
• New exports: describeCapability(), checkRequirements(), and the types ExtensionCapability, CapabilityText, DescribedCapability, AboutExtension, UnavailableCapability, ExtensionRequirement, RequirementCheck.
• @falkenslab/agent-kit-catalog 0.2.0 writes and checks capabilities and requirements in catalog.json; both schemas in schemas/ describe them.

Breaking changes

• needs is gone. Declare requirements instead: "needs": ["docker"] becomes "requirements": [{ "name": "Docker", "program": "docker", "install": { "url": "https://docs.docker.com/get-docker/" } }].
• addExtension(), installFromMarketplace() and installExtension() also return missing: what the extension needs and this computer lacks, as sentences to show the person.
• ResolvedExtensions.active entries carry unavailable, and ExtensionsStatus.about entries are AboutExtension (with capabilities, unavailable and servers); SessionFacts' active extensions carry capabilities and unavailable.

Internal

• Two tests that failed at random under the whole suite's load now wait for what they check instead of a fixed time.

Captain Whiskers

Captain Whiskers 0.4.0, the example agent built on agent-kit 0.23.0, as a Windows app: download the installer. It's unsigned, so SmartScreen warns about it; it asks for a Claude key on first start and keeps everything in ~/.captain-whiskers. New: his jokebook (1.3.0) declares its capabilities, "Pirate jokes" and "Ranking jokes", which /extensions and the drawer show in his language; the drawer's details also say what an extension needs on the computer. An installed jokebook shows an update to 1.3.0.

v0.22.0

Installed extensions grow up: they are plain Claude Code plugins, configurable, installable from a catalog in the chats, and safe to share with a workspace. The documentation has a new Extensions section, with a tutorial that builds an extension with its own MCP server from scratch.

New features

• Extensions are valid Claude Code plugins. The kit's own data (labels, capabilities, read-only tools, help, catalog look) moves under metadata["agent-kit"] in plugin.json, which Claude Code ignores, so one folder serves both.
• Options. An extension's userConfig settings are asked at install (extension add … --set key=value), set with extension config or /extensions config, kept per scope (secrets apart, out of the file tools' reach), and applied live: only that extension's servers restart.
• npx servers. A server declared as npx -y <package>@<exact version> is fetched by the kit into the agent's folder, checked against its integrity and run with the agent's own Node: no npx needed, also inside a packaged desktop app.
• The catalog in the chats. /extensions search|install|update|remove|reload, and the chat controller's extensionCatalog(), extensionImage(), installExtension(), updateExtension(), removeExtension(), extensionOptions(), setExtensionOptions() and reopen() for a host of its own. Extensions carry topics, a logo and a banner; catalogTopics filters what an agent offers, and officialMarketplace names the agent's own marketplace, installed from without a question.
• Workspaces. A project scope keeps only its lock; the code lives in the agent's store and is fetched with extension restore. A workspace's extensions run only once trusted (extension trust, /extensions trust, the controller's trustWorkspace()), and trust is lost when their code changes.
• MCP elicitation. A server can ask the person a form, through a port's askForm (field by field where there's none), never through the model.
• Plan mode trusts readOnlyHint for an installed server whose manifest lists no read-only tools.
• The marketplace catalog's contract. JSON schemas for metadata["agent-kit"] and for a marketplace's catalog.json ship in schemas/, and the new package @falkenslab/agent-kit-catalog writes and checks a marketplace's catalog.json (npx @falkenslab/agent-kit-catalog --check).

Fixes

• An extension's hash no longer counts text files' line endings, so a checkout with CRLF matches its lock.

Breaking changes

• metadata["agent-kit"]. The kit's fields in plugin.json (kit, provides, requires, needs, readOnlyTools, labels, help) move under metadata["agent-kit"]. Move them there; claude plugin validate --strict must pass.
• Hashes changed. Extensions installed with 0.21 no longer match their lock: reinstall them (extension remove <name>, then extension add …), including the jokebook in ~/.captain-whiskers.
• Workspace layout. A project scope keeps only extensions.lock.json; its extensions' code goes to the agent's store and its data to <agent>/.projects/. Reinstall a project's extensions with --project, then extension trust.
• SDK 0.3.300 (CLI 2.1.300), needed for userConfig options.

Captain Whiskers

Captain Whiskers 0.3.0, the example agent built on agent-kit 0.22.0, as a Windows app: download the installer. It's unsigned, so SmartScreen warns about it; it asks for a Claude key on first start and keeps everything in ~/.captain-whiskers. New: an extensions drawer with the catalog (logos, topics, search), settings, updates and uninstall, and his jokebook from his own marketplace.

v0.21.0

New features

• An installed extension's data folder (#52): ${CLAUDE_PLUGIN_DATA} in its servers' args and env, as in Claude Code, is <scope>/.data/<name>/: outside its plugin and its hash, kept across reinstalls and updates. Keep there what must last (a browser profile with a signed-in session, a cache). Its servers also get CLAUDE_PLUGIN_ROOT and CLAUDE_PLUGIN_DATA as variables. extension remove asks before deleting it (--yes deletes it, --keep-data keeps it); extension info shows it and its size. extensionDataDir() is exported.
• Developing an extension linked (#52): extension add <folder> --link registers the folder where it is: run from there, its files not checked against a hash. A rebuild takes effect when its server starts again; in the chat, /extensions disable and enable turn a linked one back on with its new files. extension list shows it as linked, and extension remove leaves the folder.

Fixes

• An installed extension finds the system's browsers. The launcher's clean environment had no PROGRAMFILES, so Playwright found no Edge or Chrome from an installed extension. It now keeps the system's variables a program needs to find and open another (PROGRAMFILES, PROGRAMFILES(X86), PROGRAMDATA, DISPLAY, WAYLAND_DISPLAY, XDG_*…), still never a credential.

Performance

• Installed extensions' plugins are mounted as links, not copies. Every session copied each installed extension's whole plugin into its run folder, node_modules included, and run folders are kept for resuming. Now it's a link (a junction on Windows, no privilege needed), removed and made again to turn the extension off and on; a copy only where a link can't be made.

Confirmed SDK behavior

• Turning a stdio MCP server off, or closing the session, ends its whole process tree: a browser it opened with Playwright closes with it, and its profile isn't left locked (Windows; a test checks it wherever the CLI's binary is).
• A plugin loads through a link, and reloadPlugins() unloads it when the link goes and loads it when it's back.

Captain Whiskers

Captain Whiskers 0.2.0, the example agent built on agent-kit 0.21.0, as a Windows app: download the installer. It's unsigned, so SmartScreen warns about it; it asks for a Claude key on first start and keeps everything in ~/.captain-whiskers.

v0.20.0

New features

• Marketplaces (#29): extensions install from Claude Code marketplaces (marketplace.json). extension marketplace add|list|update|remove, extension search, extension add <plugin>@<marketplace>. Folder, github, url, git-subdir, npm (checked against the registry's sha512 integrity) and archive (a zip over HTTPS, checked against its sha256) sources; command sources never install. An agent's own marketplace is official and installs without asking; another asks for its name to be typed, and installing from it asks again (--yes answers for the person). npm and zip downloads are unpacked in-process (optional fflate), so a packaged agent needs neither npm nor tar, and nothing in them runs. Exports: addMarketplace(), listMarketplaces(), updateMarketplace(), removeMarketplace(), findPlugin(), installFromMarketplace(), readMarketplaceManifest(), inspectMarketplace().
• Extensions on and off in a running session (#49): /extensions disable|enable on an installed extension takes effect without reopening the session (its tools, skills, commands and subagents go and come back); buildSessionOptions() returns switchExtension. The model is told what changed.
• An extension declares the programs it needs (needs in its manifest): one whose program isn't on the PATH is off, with why; extension info shows them.
• Denied paths as the SDK's own rules too: deniedPaths (and the SDK's credentials) also go to settings.permissions.deny, a second layer under the file scope gate. denyRules() is exported.
• Each extension owns its options (#50): the kit's extensions are factories, exported from the package root: awareness({ guide }), sources({ dir, saveDescription }), knowledge({ dir, pageTypes, store }), memory({ dir }). A folder is a path or a function of the session's config (FolderOption). ExtensionContext.capabilities tells an extension what the active ones provide.

Breaking changes

• AgentSpec.extensions takes Extension objects only: extensions: ["sources", "knowledge"] becomes extensions: [sources({ dir }), knowledge({ dir })].
• Removed from BaseSessionConfig: knowledgeDir, sourcesDir, memoryDir; pass them to knowledge({ dir }), sources({ dir }), memory({ dir }), e.g. knowledge({ dir: (config) => path.join(config.projectDir, "knowledge") }).
• Removed from AgentSpec: helpGuide (now awareness({ guide })), saveToSourcesDescription (sources({ saveDescription })), knowledgePageTypes (knowledge({ pageTypes })), knowledgeStore(config) (knowledge({ store: (config, dir) => … })). identity stays.
• buildSessionOptions() no longer returns knowledgeStore: read apis.knowledge.knowledgeStore.
• A folder of plain notes (formerly knowledgeDir without the knowledge extension) is an extraWritableDirs entry.
• The knowledge base explains matching summaries to originals when the sources extension is active, not when a sources folder is configured.

Captain Whiskers

Captain Whiskers 0.2.0, the example agent built on agent-kit 0.20.0, as a Windows app: download the installer. It's unsigned, so SmartScreen warns about it; it asks for a Claude key on first start and keeps everything in ~/.captain-whiskers. New: his own marketplace, the shipyard, from which his jokebook installs; his extensions through their factories.

Internal

• The core imports no extension, not even a type; ESLint enforces it.
• The shipyard is checked with claude plugin validate by a test.

v0.19.0

Extensions, a memory of the person, self-awareness, and everything a graphical host needs: the controller, packaging in Electron, the language switched on the fly. And from now on, Captain Whiskers as a Windows app with every release.

Try it: Captain Whiskers 0.1.0

The kit's example agent, a retired pirate cat who tells jokes and learns from your documents, built on agent-kit 0.19.0, as a Windows app: download Captain-Whiskers-Setup-0.1.0.exe below. Everything is inside, the Claude CLI included. It's unsigned, so SmartScreen warns about it; it asks for a Claude key on first start and keeps everything in ~/.captain-whiskers, shared with his terminal and browser faces.

New features

• Extensions (guide): what an agent runs with besides the core. The kit's own (awareness, sources, knowledge, memory) and the agent's, enabled in AgentSpec.extensions, with capabilities they provides and requires; installed ones per agent or per project (extensionDirs, runExtensionCommand(), /extensions in the chat), locked by hash and run through a launcher with a clean environment. Any Claude Code plugin is an installable extension as it is. An extension labels its own tools in the chat, a plugin's subagents are registered like the agent's own, and an extension can hand the host an API (buildSessionOptions().apis, the controller's api(name); the sources' addSource()).
• Memory of the person (memory extension, memoryDir): who the person is and how they want things done, across all their projects, kept only from what they write; tools recall, remember, forget.
• Awareness (awareness extension, needs identity): the agent knows what it is right now. about_me reads the session live (mode after Shift+Tab, extensions and their tools, what's off and why, subagents, commands, context) and gives the agent's helpGuide; the help skill explains the chat. Every extension can read the same facts through ExtensionContext.session() (SessionFacts).
• A chat controller without an interface (createChatController()): the chat's logic as plain state and actions, for a desktop app or a server; the terminal chats are its views. Commands with descriptions (commandDetails), newConversation(), setExtension(), setLanguage(language, { note }).
• Packaged in Electron: an agent runs from app.asar with only asarUnpack (the kit points the CLI at the unpacked binary and its plugins).
• The language switched on the fly: switchLanguage(), and the controller's setLanguage() reopens the session keeping the conversation.

Breaking changes

• Extensions are enabled in the spec. knowledgeDir and sourcesDir no longer turn the knowledge base and the sources on by themselves, and knowledgeBase: false is gone: add extensions: ["sources", "knowledge"] (with the folders still in the config).
• agent-help is gone, replaced by the awareness extension. identity and helpGuide reach the model only with extensions: [..., "awareness"]; the skill is now awareness:help, and identityPromptSection/agent-kit:agent-help no longer exist.
• The memory's tools are recall, remember and forget.
• Moved modules: the knowledge base and the sources live under extensions/; imports from the package root are unchanged.

Internal

• The terminal chats are views of the controller; the knowledge base and the sources became internal extensions.
• Captain Whiskers runs in a terminal, a browser and as a desktop app, all on ~/.captain-whiskers, and his installer is now part of each release.

v0.18.0

This release changes defaults directly and removes options instead of deprecating them: while the version is 0.x, agent-kit keeps no backward compatibility. See the breaking changes below.

Breaking changes

• Read and Glob only reach the agent's own folders (#28). They used to reach any file the user could, but deniedPaths: ~/.ssh, other projects' .env, the SDK's credentials.
  • Now they reach sourcesDir, extraWritableDirs, the new BaseSessionConfig.extraReadableDirs (read and searched, never written), and what the kit knows the agent needs: the run folder, the plugins, the project's .claude/ and the SDK's large tool results.
  • The project folder itself isn't readable.
  • Glob follows Read's rules and always respects deniedPaths.
  • The SDK's credentials are always denied.
  • Migration: list in extraReadableDirs any folder the agent reads outside its own.
• The knowledge base has one way in, its knowledge_* tools (#31).
  • AgentSpec.knowledgeTools: "files", assets/knowledge-plugin-files/ and knowledgePluginRoot()'s variant are gone.
  • Migration: an agent with its own rules for its notes uses knowledgeBase: false.
• The sources and the knowledge base each own their data, and the model connects them (#30). With a store that isn't the kit's files, the ingest status used to be wrong.
  • list_sources lists originals as present, missing or retired (when, why, what replaced it). Each has changedAt, when its content last changed. It no longer reports new/ingested/changed, nor summaries.
  • retire_source only retires: the model then retires or supersedes the summaries with the knowledge tools.
  • A summary's ingested is set by the store when it's created or rewritten. Its file is kept as given (relative to the sources folder). The index shows both, by page id.
  • knowledge_check keeps to links, orphans and links to retired pages.
  • The sources have their own prompt section (sourcesPromptSection), with or without a knowledge base.
  • Gone or changed: listSources(sourcesDir), retireSource(sourcesDir, …), knowledgePromptSection({ withSources, pageTypes, preferences }), recordIngest, CheckReport.missingOriginals, and the sourcesDir options of createFileKnowledgeStore and createKnowledgeServer.

New features

• The person's preferences in the project's knowledge base (#33).
  • A fifth kit page type, preference, holds how the person wants things done in this project ("rubrics go in tables").
  • The knowledge base's prompt section lists them by title, up to 20, and tells the agent to save one as its first action when the person states or corrects a way of working.
  • Only from what the person says in the chat, never from a document, page or tool result.
• skills: "plugins" offers only the skills of the plugins the session loads (the agent's, the knowledge base's, agent-help's), without naming them. Without it, a session offers about twenty skills that come with the SDK itself.

Fixes

• Sessions no longer inherit the runner's claude.ai connectors (Drive, Gmail…), which the CLI loads whatever settingSources says (#32).
• Pages are written in the language the agent replies in. The tools asked for "the person's language", which the model read as the language of the account's name: an English chat got Spanish pages. The language line now covers everything the agent keeps.
• knowledge_index links pages by id, not by file path; index.md on disk keeps file links.
• Retiring a page asks the person once: the tool asks itself, and the model no longer asks first.
• A page body sent with escaped newlines gets them back.

Documentation

• "Knowledge base and sources", "The person's preferences" and "What the agent can read" sections.
• SDK behaviors found on the way: plugin skills are named after their folder; about twenty skills ship with the SDK; claude.ai connectors; how the language of the person's name pulls what the agent writes.
• ADR-025 records the design of extensions on Claude Code plugins and marketplaces (#29), whose next phases come in later releases.

v0.17.0

New features

• The agent knows who it is and how its chat is used (#24).
  • AgentSpec.identity ({ name, version?, description? }) adds a "Who you are" section to the system prompt, with the agent's name, version and what it is, plus agent-kit's version.
  • With an identity, the session also offers the agent-kit:agent-help skill, so the agent can answer "how do I resume a conversation?" or "what does Shift+Tab do?" instead of improvising. The skill combines the kit's part of the chat (modes, approvals, keys, slash commands, resuming, --continue, --language), this session's facts, and the agent's own guide (AgentSpec.helpGuide, a markdown file).
  • Without an identity, nothing changes.
• Bash only when a subagent uses it (#25). A session used to get Bash whenever the spec registered subagents. Now it gets it only when a subagent lists it in its tools, or has no tools (and so inherits them all). That saves about 1.9k input tokens per call for agents whose subagents don't use it. Agent and the three subagent gates are unchanged.

Fixes

• The status bar shows cached input apart: 26.6k in (+126.7k cached) / 1.4k out. The "in" count included the context read again from the cache on every call, so it grew several times faster than the context and looked like the context growing. The cached part is left out when the terminal is too narrow. SessionUsage gains cacheReadTokens; inputTokens keeps its meaning.

Documentation

• disallowedTools takes a built-in tool out of the context, but an MCP tool is only blocked: its definition is still sent (#26). "Context and cost" now has what each part of the kit costs per call, and what makes it go away.
• Captain Whiskers sets his identity and ships a help guide, with a new section and screenshot in his guide.

No breaking changes. If you relied on Bash being in the session without any subagent listing it, list it in that subagent's tools.

v0.16.1

Fixes

• The task list (TodoWrite) reaches the model in a real terminal. The CLI only offers TodoWrite with CLAUDE_CODE_ENABLE_TASKS=0; by default it offers its own TaskCreate/TaskUpdate/TaskList/TaskGet tools and drops TodoWrite, even when the session lists it. In 0.16.0, outside a Claude Code session, agents never had the task list. The session's env is now process.env plus CLAUDE_CODE_ENABLE_TASKS=0.
• The sources tools name the folder as it really is. Their results and descriptions said sources/ whatever sourcesDir was called, so an agent with another folder name (Captain Whiskers' treasure/) was sent to read paths that didn't exist. They now use the folder's path, and accept paths starting with either name.
• Links to the overview aren't reported as broken by knowledge_check (knowledge bases written with the file tools link overview.md) (#22).

Additions

• knowledge_read("log"): the latest entries of the knowledge base's operation log, newest first, through a new optional KnowledgeStore.recentLog() (#23).
• agentKitVersion(): the version of agent-kit in use, e.g. for an agent's header.

Documentation

• The Captain Whiskers guide opens with a tour of what he can do, with a screenshot of each feature, and a new main screenshot.

No breaking changes.