goose now supports lifecycle hooks. Drop a plugin into a directory on disk and goose will run your shell scripts when things happen during a session: a tool is about to fire, a tool just finished, the user submitted a prompt, the session started, the session ended.

If you've used Claude Code's hooks or git hooks, it's the same idea. If you haven't: the agent loop is now scriptable from the outside, without writing any Rust or any MCP server.

How it works​

goose follows the Open Plugins hooks specification. Any plugin directory under ~/.agents/plugins/<name>/ (user scope) or <project>/.agents/plugins/<name>/ (project scope) that contains a hooks/hooks.json file is auto-discovered at startup.

A minimal hook config looks like this:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "developer__shell|developer__text_editor",
        "hooks": [
          { "type": "command", "command": "${PLUGIN_ROOT}/scripts/log.sh" }
        ]
      }
    ]
  }
}

When the event fires, goose runs the command, sets PLUGIN_ROOT in the environment, and pipes a JSON payload to the script on stdin:

{
  "event": "PostToolUse",
  "session_id": "abc-123",
  "tool_name": "developer__shell",
  "tool_input": { "command": "rg TODO" },
  "working_dir": "/Users/you/project"
}

The supported events are:

• SessionStart, SessionEnd, Stop
• UserPromptSubmit
• PreToolUse, PostToolUse, PostToolUseFailure
• BeforeReadFile, AfterFileEdit
• BeforeShellExecution, AfterShellExecution

The matcher field is a regex tested against the most relevant string for the event (tool name, file path, or shell command). Leave it off and the hook fires for every event of that type. Hooks that fail or time out are logged but won't crash the host tool, so your scripts can be as scrappy as you want.

A few things to try​

1. Have goose talk to you when it actually needs you​

Pick a handful of events that mean "the human's attention would be useful right now" — a tool failed, the session wrapped, a long-running command finished — and have goose speak a line when one of them fires:

{
  "hooks": {
    "PostToolUseFailure": [{ "hooks": [{ "type": "command", "command": "${PLUGIN_ROOT}/scripts/notify.sh" }] }],
    "SessionEnd":         [{ "hooks": [{ "type": "command", "command": "${PLUGIN_ROOT}/scripts/notify.sh" }] }],
    "AfterShellExecution": [
      {
        "matcher": "^(cargo (test|build|clippy)|pnpm (test|build)|just )",
        "hooks": [{ "type": "command", "command": "${PLUGIN_ROOT}/scripts/notify.sh" }]
      }
    ]
  }
}

Then notify.sh branches on the payload and picks a line:

#!/usr/bin/env bash
payload="$(cat)"
event="$(printf '%s' "$payload" | jq -r .event)"

case "$event" in
  PostToolUseFailure)  echo "That didn't work. Need a hand?" | say -v Daniel ;;
  SessionEnd)          echo "Done. Come check this out."     | say -v Daniel ;;
  AfterShellExecution) echo "Long command finished."         | say -v Daniel ;;
esac

Tune the matcher regex to whatever counts as "long-running" in your world — test suites, builds, deploys, terraform apply.

2. The "goose is doing something" desk light 🪿💡​

If you have a smart bulb with an HTTP API (Hue, LIFX, Home Assistant, etc.), turn it on when goose starts a tool call and off when it finishes:

{
  "hooks": {
    "PreToolUse":  [{ "hooks": [{ "type": "command", "command": "curl -s -X POST http://hue.local/light/on"  }] }],
    "PostToolUse": [{ "hooks": [{ "type": "command", "command": "curl -s -X POST http://hue.local/light/off" }] }]
  }
}

Now your desk lamp is a status indicator for the agent. Walk away, glance back, and if it's on, goose is still working.

3. Auto-format every file goose edits​

Hook AfterFileEdit and run the formatter yourself so the agent doesn't have to remember:

{
  "hooks": {
    "AfterFileEdit": [
      {
        "matcher": "\\.(ts|tsx|js|jsx|json|md)$",
        "hooks": [{ "type": "command", "command": "${PLUGIN_ROOT}/scripts/format.sh" }]
      },
      {
        "matcher": "\\.rs$",
        "hooks": [{ "type": "command", "command": "cargo fmt" }]
      }
    ]
  }
}

scripts/format.sh reads the file path from stdin and runs prettier --write against it.

4. Daily session journal​

Hook SessionEnd and append a one-line summary to a markdown file:

#!/usr/bin/env bash
payload="$(cat)"
session_id="$(printf '%s' "$payload" | jq -r .session_id)"
date_str="$(date '+%Y-%m-%d %H:%M')"
echo "- $date_str — session $session_id ended" >> ~/notes/goose-journal.md

Capture UserPromptSubmit payloads too and you've got a log of every question you asked your agent today.

5. Make goose sound like a submarine​

Because you can:

{
  "hooks": {
    "PreToolUse": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "afplay /System/Library/Sounds/Submarine.aiff"
          }
        ]
      }
    ],
    "SessionEnd": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "say 'Captain, the session has ended.'"
          }
        ]
      }
    ]
  }
}

Useful when goose is working on a long task in another window. The audio cue tells you it's actually doing things instead of sitting there waiting on you.

Try the example​

There's a working example in the repo at examples/plugins/hello-hooks — a plugin that wires up SessionStart, UserPromptSubmit, PreToolUse, and PostToolUse and prints a friendly emoji to stderr for each one. Copy it to ~/.agents/plugins/, start a session, and watch the events fly by:

mkdir -p ~/.agents/plugins
cp -R examples/plugins/hello-hooks ~/.agents/plugins/hello-hooks
chmod +x ~/.agents/plugins/hello-hooks/scripts/announce.sh

goose session
# 🚀 [hello-hooks] SessionStart
# 💬 [hello-hooks] UserPromptSubmit
# ⚡ [hello-hooks] PreToolUse tool=developer__shell
# ✅ [hello-hooks] PostToolUse tool=developer__shell

Every event also gets appended to ~/.agents/plugins/hello-hooks/last-event.log so you can see the exact JSON your scripts receive. Fire some events, tail the log, build from there.

Why this matters​

MCP servers give goose new tools. Hooks go the other direction: they give you a way to react to what goose is doing, in real time, with whatever language you already know. Bash, Python, a Go binary, a one-line curl. It's all just a command on stdin.

The plugin model is small on purpose: a folder, a JSON file, a script. No registration step, no daemon, no rebuild. Drop it in, start goose, it works. Take it out and goose doesn't notice it's gone.

If you build something fun, share it. The examples/plugins/ directory is a good home for community plugins, and the Open Plugins spec means anything you build here works with other agents that adopt it.

Happy hooking. 🪝

A lot of people prompt their agents one task at a time — "do this, now do that, now do the next thing." It works, but it's slow. Many people also want their agents doing many things at once: researching while coding, reviewing while testing, writing docs while refactoring.

That's what orchestration gives you. Instead of feeding goose one task at a time and waiting, you can have it coordinate multiple agents working in parallel — each focused on a specific piece of the puzzle, with goose keeping everything on track.

What is orchestration?​

If you've used subagents before, you already know how to delegate work to independent AI instances. Orchestration is the layer above that — the part that decides who does what and when. Instead of one goose session doing everything sequentially, orchestration lets you:

• Decompose a complex task into independent subtasks
• Delegate each subtask to a separate agent (subagent, ACP provider, or another goose instance)
• Coordinate the results — waiting for dependencies, handling failures, merging outputs

Think of it as the difference between a solo developer and a tech lead managing a team.

Try it yourself​

Here's something you can run right now to see orchestration in action. Ask goose:

I need to understand this codebase. In parallel:
- Summarize the project structure and key dependencies
- Identify the main entry points and how data flows through them
- Find any TODO comments or known issues in the code

goose will spin up three subagents simultaneously — one for each research task. You'll see them working at the same time in your session, and all three summaries come back roughly together instead of one after another. What would've been three sequential waits becomes one.

How it builds on what already exists​

Orchestration doesn't replace subagents or subrecipes — it builds on them:

If subagents are your teammates, orchestration is the project plan that tells them what to do and when.

Phased workflows: research → build → verify​

Not everything can run in parallel. Some workflows have natural phases where later steps depend on earlier results. You can describe this to goose naturally:

Build a REST API for the inventory system:
1. First, research the existing data models in src/models/ and the API patterns in src/routes/ (do both at the same time)
2. Then implement the inventory API routes following those patterns
3. Finally, write integration tests and do a security review (both at the same time)

goose understands the dependency structure here. Phase 1 runs two research tasks in parallel. Phase 2 waits for those results before building. Phase 3 kicks off two independent verification tasks in parallel.

The key insight: reads can be parallel, writes should be sequential (especially if they touch the same files).

Orchestration + ACP: mixing agents​

Here's where things get really interesting. Orchestration works with ACP providers, which means you can delegate to entirely different coding agents — not just goose subagents.

To use them, you just say so in your prompt, e.g:

Refactor the auth module for clarity using Claude Code,
then write tests for it, and use Codex to generate the API docs.

goose understands that you want different agents handling different parts of the workflow. It delegates each task to the right agent, waits for the results, and brings everything together. This works the same whether you're on the CLI or the desktop app — you just ask in natural language.

The only prerequisite is having the provider configured for whichever agents you want to use.

Best practices​

When you start orchestrating, it's important to do this with tasks that are conceptually separate and will be less likely to result in edit conflicts on shared files. Here are some tips:

Parallelize your reads​

Research tasks are safe to run in parallel. Multiple agents can read the same codebase, docs, or APIs simultaneously without stepping on each other.

Be explicit in instructions​

Delegates only know what you tell them. They don't share context with each other or with the parent session. If a delegate needs information from a previous phase, pass it explicitly in the instructions.

Start simple​

You don't need to orchestrate everything. A single subagent is fine for straightforward tasks. Orchestration shines when you have genuinely independent work streams or need multiple perspectives on the same problem.

Get started​

If you're already using goose, you can start orchestrating today. The simplest way is just to ask:

Do these three things in parallel: [task A], [task B], [task C]

goose handles the rest — spinning up delegates, running them concurrently, and bringing the results together.

For reusable workflows, check out the subrecipes in parallel tutorial to build recipes you can share with your team. And if you want to bring in external agents, the ACP providers guide will get you set up with Claude Code, Codex, or Amp.

Highlights from the linked article:

• Using goose with MiniMax M2.5 on the OfficeQA benchmark from Databricks, we're seeing results approaching frontier model performance for 1/30th of the cost.
• Closed-source wins on accuracy (~80% vs ~70%), but MiniMax M2.5 ran at an average of $1.74 per run versus $56.53 for Opus 4.5. That's roughly 30× cheaper.
• Switching to the @goose_oss harness beat alternatives by ~10% in accuracy and was 8× cheaper than the next option. We decided to further investigate this with independent testing. On Terminal Bench 2.0, we found a similar story—goose was 20x more token efficient (and cheaper) than OpenHands, and more than 40x cheaper than OpenCode.

Check out the full post and results here:

https://x.com/SentientAGI/status/2046967422004154739

Most AI agents live in the terminal. They can read files, run commands, and write code — but ask them to click a button in a web app or fill out a form, and they're stuck. They can't see what's on screen, and they certainly can't interact with it.

With v1.26, goose broke out of the terminal. The Computer Controller extension was rebuilt from the ground up with Peekaboo, a macOS CLI tool for screen capture and GUI automation. This gives goose eyes and hands for the desktop — it can see annotated screenshots, identify UI elements, click buttons, type text, scroll, drag, and navigate menus across any application on your Mac.

The see → click → type loop​

The core workflow is dead simple and surprisingly reliable:

1. See — goose takes an annotated screenshot of an app. Every clickable element gets a labeled ID like B1, B2, T1.
2. Click — goose clicks on an element by its ID. No fragile pixel coordinates.
3. Type — goose types text, presses keys, or uses keyboard shortcuts.

Because element IDs are tied to actual UI components (not screen positions), this approach adapts to different window sizes and positions. goose doesn't need to know where a button is on screen — just what it is.

Here's what that looks like in practice:

goose: Let me see what's on screen...
→ see --app Safari --annotate

goose: I can see the form. Clicking on the email field...
→ click --on T3
→ type "hello@example.com" --return

The see command returns both an annotated screenshot (that is stored temporarily in memory) and structured JSON data with element IDs, labels, and types. This combination of vision and structure is what makes the interaction reliable.

What can goose actually do with this?​

Once goose can see and interact with your screen, the range of tasks it can handle expands dramatically. Here are some real examples:

Fill out forms​

"Go to the HR portal and submit my time off request for next Friday"

goose opens the browser, navigates to the page, identifies the form fields, fills them in, and clicks submit — all by seeing the UI and interacting with it step by step.

Navigate complex UIs​

"Open Figma, find the design called 'Homepage Redesign', and export it as PNG"

Multi-step workflows across apps that don't have APIs become possible. goose can click through menus, search within apps, and follow multi-screen flows.

Control system settings​

"Turn on Do Not Disturb and set my display brightness to 50%"

System preferences, menu bar items, and macOS settings are all accessible through Peekaboo's menu, menubar, and dialog commands.

Automate repetitive GUI tasks​

"For each PDF in my Downloads folder, open it in Preview and print it"

goose can combine its existing file system and shell capabilities with GUI automation — reading a directory listing, then opening and interacting with each file visually.

The full command toolkit​

Peekaboo gives goose a comprehensive set of commands for interacting with macOS across vision, interaction, and system control. Check out the Peekaboo docs for a full list. Some highlights:

• see — capture an annotated screenshot and get structured UI data
• click — click on an element by its ID
• type — type text or press keys
• scroll — scroll within an element
• drag — click and drag from one element to another
• menu — interact with menu bar items
• dialog — interact with system dialogs and notifications

Tips for best results​

After using the Computer Controller extensively, here are a few things that help:

• Don't touch your mouse while goose is working. goose takes screenshots and clicks based on what it sees. If you move things around mid-task, it'll get confused.
• Be specific in your prompts. "Click the blue Submit button at the bottom of the form" gives goose much more to work with than "submit it."
• Let goose see first. goose will naturally start with a see command to understand the current UI state before taking action. If you're debugging an interaction, ask goose to take a fresh screenshot.
• Long text goes through paste. For reliability, goose uses paste instead of type when entering longer content. This avoids issues with special characters and typing speed.

Current limitations​

The Computer Controller is powerful, but it's worth knowing the boundaries:

• macOS only (for now) — Peekaboo is built on macOS accessibility APIs. On Windows and Linux, the Computer Controller falls back to shell-based automation (PowerShell scripts on Windows, xdotool/wmctrl on Linux).
• Fast-changing UIs can be tricky — Videos, animations, and rapidly updating content can cause goose to see stale state. Static or slow-changing UIs work best.
• Standard UI elements work best — Custom-rendered canvases (like some game UIs or heavily custom web apps) may not expose accessibility labels that Peekaboo can identify.
• One screen at a time — goose works with one screenshot per see command, though you can target specific screens in multi-monitor setups with --screen-index.

Try it out​

The Computer Controller extension is built into goose — just enable it in your extensions and start asking goose to do visual tasks. If you're on macOS, Peekaboo will handle the rest.

In goose Desktop, go to Extensions and toggle on Computer Controller. In the CLI:

goose configure
# → Toggle Extensions → enable computercontroller

Then try something simple:

Take a screenshot of my current screen and describe what you see.

Or something more ambitious:

Open System Settings, go to Displays, and set the resolution to "More Space."

goose will figure out the rest — seeing the UI, identifying the right elements, and clicking through to get it done.

You can now run local models with goose directly on your machine. No Ollama, no Docker, no external server — just entirely within goose. We shipped built-in local inference powered by llama.cpp, and it's already available today in the desktop app.

This is the completely free, zero-dependency path to using goose. Your code never leaves your machine, there's no API key to manage, and it works offline. Here's what the experience looks like, which models to pick, and where the rough edges still are.

How it works​

goose now embeds llama.cpp directly into its runtime. When you select the Local provider, goose downloads a quantized GGUF model from HuggingFace, loads it into your GPU (or CPU) memory, and runs inference in-process.

There's no separate server to start, no port to configure, no background daemon.

How to do this on the desktop app:

1. Open Settings → Local Inference
2. Browse the featured model list — goose recommends the best one for your available memory or you can search for specific models of your choice.
3. Click download — the model file lands in goose’s data directory under models
4. Start building. That's it.

goose handles the details: GPU offloading, memory management, context window sizing, and automatic model unloading when you switch between models.

What makes this different from Ollama​

You might already be familiar with using goose via the Ollama provider. Both paths run models locally, but the architecture is different:

The built-in path is designed for people who want the simplest possible local experience — one app, one download, done. Ollama is still great if you want more control, a wider model selection, or you're already using it for other tools.

Featured models​

goose ships with a curated list of models that are tested and known to work well. As at the time of this writing, the featured models include:

• Llama 3.2 3B (GGUF) — a small, fast model good for basic tasks and shell command generation.
• Mistral Small 24B (GGUF) — a larger model with strong reasoning capabilities, but slower on CPU.
• Hermes 2 Pro Mistral 7B (GGUF) — a 7 billion parameter model optimized for instruction following and coding tasks.
• Gemma 4 E4B (GGUF) — a 4 billion parameter variant of Google's Gemma 4, optimized for local inference with native tool calling support.
• Gemma 4 26B-A4B (GGUF) — a 26 billion parameter variant of Gemma 4 with native tool calling and vision support, for users who want stronger local performance and have enough available memory.

What to expect​

There is some cost that comes with choosing to use a local model - the biggest of which is performance depending on the capabilities of your hardware. Compared to cloud models:

It's slower. The first request takes 30–120 seconds while the model loads into memory. After that, token generation is fast on Apple Silicon (especially M2/M3/M4) but noticeably slower on CPU-only machines.

Context windows are smaller. Most local models work with 4K–8K tokens of context, compared to 128K+ for Claude or GPT. goose sets num_ctx based on your available memory, but you'll hit limits faster on long sessions. Code Mode helps here — it reduces token usage and context rot.

Tool calling is the gap. With Gemma 4, it's genuinely good. With emulated models, it's limited to shell commands. This is the single biggest difference from the cloud experience.

It's completely private. Nothing leaves your machine. No telemetry, no API calls, no data sharing. For working with proprietary code, credentials, or sensitive data, this matters.

It costs nothing. After the initial model download, every session is free. No tokens to count, no bills to worry about.

Tips for getting the most out of it​

Start with Gemma 4 E4B. It's the best balance of capability and resource usage. If it works well for your tasks, great. If you need more power, step up to the 26B variant.

Use Code Mode. Seriously. It's designed for exactly this scenario — keeping sessions productive within smaller context windows.

Let goose recommend. The automatic model recommendation is based on your actual available memory, not total RAM. Trust it for the first run.

Don't fight emulated mode. If you're using a model without native tool calling, lean into the shell-command workflow. Ask goose to do things step by step. It works well for "run this command, check the output, do the next thing" patterns.

Switch models for different tasks. You can download multiple models. Use a small fast model for quick shell tasks, and a larger one for complex reasoning. goose unloads the previous model automatically.

It uses the same llama.cpp infra as local mode to run models, with a twist.

What is Mesh LLM?​

Mesh LLM is an associated project we're trying out that lets people connect their compute capacity (which may just be a laptop) peer-to-peer, so they can access models they may not otherwise be able to self-host.

There is a demo public "mesh" which at any point has some capacity in it, but you can also make your own private networks and pool compute together. The mesh will try to work out the best places to run models (downloading them as needed) and can even split the compute in various ways.

This is a pretty early-stage project, so we'd love any feedback on it.

Check out the project docs and the live public mesh.

goose started life in the terminal. The earliest versions were a Python CLI that ran the agent in-process — you typed a message, the model responded, tools executed, and everything happened in a single loop. That simplicity was a strength: it meant anyone with a terminal could start using goose immediately, no app to install, no server to run.

As goose grew, so did the ways people wanted to use it. We shipped an Electron desktop app and suddenly we had two clients with two completely different integration paths. The Rust CLI talked to the agent directly in process, while the desktop app went through goosed, a custom REST + SSE server. Every new feature — session management, extension loading, streaming — had to be wired up in both places.

Third-party developers have never been able to easily build their own clients, as they had no standard way to connect at all.

We needed a single protocol that any client could speak to reach the same agent core. For this purpose we have chosen ACP, the Agent Client Protocol, as our new default interface to goose.

Under the hood: ACP​

Behind the scenes we're unifying how every client connects to goose through ACP (Agent Client Protocol). ACP gives us one protocol and one goose server for every client — terminal, desktop, IDE plugins, whatever you want to build. This will make it possible for an ecosystem of different goose clients to emerge. We also have an RFD for a new HTTP/WS transport for ACP and would welcome feedback on the design.

Here's where things stand:

The work is tracked in #6642.

The new goose TUI​

With that foundation in place, we're now shipping the first official clients built on top of it: a brand-new TypeScript TUI you can try today and a Tauri-based desktop app that will replace our Electron desktop application. For you, this means a faster, lighter experience in both the terminal and on the desktop — and a clear path for the community to build new client and integrations without reverse-engineering internals.

Here's what's happening and how to get started.

Try the new TUI right now​

The new TypeScript-based TUI is in beta. It already supports messages, tool calling, syntax-highlighted code, and rendered markdown. Give it a spin:

npx @aaif/goose

That's it — one command, no install. It pulls down the latest beta and starts an interactive session.

What's coming next for the TUI​

• Provider and model management
• Session list, resume, and export
• UI for MCP features and skills management

We'd love your feedback — try it out and let us know what works and what doesn't.

Desktop is moving to Tauri​

We're also rewriting the desktop app from Electron to Tauri. The Tauri rewrite gives us improved performance, a refreshed UI, and the new app will talk to ACP so both official clients will share the same protocol and server.

We will follow up with another post when the desktop is ready for beta testing.

Get involved​

This is all happening in the open. Follow along or jump in:

• Tracking issue: #6642
• Try the TUI: npx @aaif/goose
• Discord: Follow along and give feedback in #goose-2-dev.
• Feedback? Open an issue or drop a comment on #6642 — we'd love to hear from you.

The biggest shift in developer tooling over the last year wasn't the rise of agents. It was the rise of agent subscriptions. We stopped choosing LLM platforms and counting tokens. We started choosing an agent CLI and paying a flat monthly fee.

That works until you realize each agent implies a specific frontend. Cursor is its own editor (a VS Code fork). Claude Code started as a terminal-only tool. Many agents only work well inside one specific environment. Even agents with broad IDE support, like Copilot, tie deeper features to their own ecosystem. If you want a different agent in your favorite editor, you're often out of luck.

Agent Client Protocol (ACP) is a community specification led by Zed Industries that decouples agents from editors. Goose implements ACP in both directions: editors can plug into goose, and goose can plug into other agents. This post walks through what that looks like in practice today.

The Integration Problem​

Dozens of agents exist. Dozens of editors exist. Each combination requires a custom integration that has to track both sides as they ship updates. Goose learned this the hard way. Multiple community maintainers built VS Code extensions and even an IntelliJ plugin, but none could keep pace with goose's release cadence. Every goose change meant updating every plugin, and the plugins fell behind.

ACP sidesteps this. Like MCP, ACP defines a JSON-RPC protocol over stdio, but for agent-editor communication. Editors implement the client interface while agents implement the server. Capabilities like model selection, slash commands, file I/O, and terminal execution are in the ACP protocol, eliminating custom code per agent.

Use Any Editor with Goose​

Goose is listed in the ACP Agent Registry, so Zed and JetBrains can discover and install it automatically. For editors that don't read the registry yet, like Neovim with avante.nvim, the config is straightforward:

acp_providers = {
  ["goose"] = {
    command = "goose",
    args = { "acp", "--with-builtin", "developer" },
  },
},

What flows through ACP goes beyond prompts. Editors can delegate file reads (including files you haven't saved yet), run terminal commands, and present permission dialogs natively. Any MCP servers configured in your editor are automatically added as extensions for that goose session, so you don't have to configure them in two places.

See the ACP clients guide for more.

Use Any Agent with Goose​

Goose also speaks ACP as a client. It can orchestrate other agents as ACP providers. You keep goose's UI and extensions, but the underlying LLM and MCP calls go through the other agent. Today that includes Claude Code, Codex, Copilot, Gemini, Amp, and Pi.

Some agents like Gemini and Copilot speak ACP natively. Others like Claude need a small adapter installed first:

npm install -g @zed-industries/claude-agent-acp  # one-time adapter install
GOOSE_PROVIDER=claude-acp GOOSE_MODEL=current goose

Setting the model to current means "use whatever model is configured in the underlying agent."

See the ACP providers guide for the full list and setup instructions.

Where ACP Stops Today​

ACP is pre-1.0. Some things work well, some don't yet:

• Permission dialog rendering varies by editor. What looks native in Zed may render differently in Neovim.
• Not every agent honors MCP server configs passed by the client. Coverage depends on the agent.
• Model and mode switching support varies. Some agents expose a full model list, others expose aliases.
• The protocol is still stabilizing. Features move between stability tiers as implementations mature.

These are real edges. The protocol is young. The direction is right.

Where to Next​

Goose currently has separate code paths for its desktop app, CLI, and ACP server. That's converging. The goose daemon is transitioning to ACP as its protocol, so every frontend becomes a thin ACP client talking to the same backend. Provider selection and config changes happen over ACP custom requests instead of per-frontend logic.

On the provider side, adding a new ACP agent to goose today means writing a Rust file. Declarative ACP providers would replace those files with JSON configs, making it possible to add agents without recompiling goose. Combined with native support for the ACP Agent Registry, goose could discover and offer new agents as they appear in the registry, no release required.

Try It​

Goose was recently donated to the Agentic AI Foundation (AAIF) inside the Linux Foundation. Interoperability is the thesis: goose shouldn't lock you into one agent or one editor.

I'm walking through this architecture at AI Native DevCon, where every slide links to the PR or GitHub discussion behind it.

Pick the UI you like. Pick the agent you like. They don't have to be the same thing.

• ACP clients guide
• ACP providers guide
• Goose on GitHub
• Discord community

While nothing changes with goose's dedication to its mission and community, here's what's changed;

New Documentation site​

The documentation has moved to a new site: https://goose-docs.ai/ with a nice .ai TLD! The old docs links will redirect, but update your bookmarks to the new site.

Updated GitHub repository​

The GitHub repository and related projects have moved from block/goose to a new org:

https://github.com/aaif-goose/goose

This includes related repositories in the aaif-goose organization.

Everything else — the project, the community, the mission — remains the same. goose is still open source, still actively developed, and still the same agent you know.

Update your remotes​

If you have a local clone, update your git remote:

git remote set-url origin git@github.com:aaif-goose/goose.git

Migration in progress​

We're still working through some migration issues (broken links, redirects, CI, etc). If you hit anything that seems off, please reach out on Discord and let us know.

Learn more​

Visit aaif.io to learn more about the foundation and its mission.

One of the desires of goose (well for some of us) was to avoid the constant asking for permissions, delegating all the decisions to end users in an attempt to keep agent execution of tools safe. Sometimes that gets pretty noisy and annoying and ends up being less secure when you get tired of reading and approving.

You can of course adjust settings as you see fit, but it is nice to consider how things could be made safe without assuming that you can interrupt the user constantly for permission, especially around things they may not currently have the context for (in their head!)

In goose there are layers of things you can enable, but we wanted to also think about general solutions when we observed agents (of all kinds) being really helpful, and as a side effect, being accidentally harmful. This birthed "adversary mode" where the idea is: why not use another agent to fight fire with fire. Agents want to be helpful, and they can be oriented to help the user, but another one can be oriented to protect against the agent "helping" the user, to keep things in policy, and safe.

What Is Adversary Mode?​

Adversary mode adds a silent, independent reviewer that evaluates every sensitive call before it executes, when needed. Think of it as a security-minded colleague looking over the agent's shoulder — one that knows what you originally asked for and can spot when something doesn't add up. This uses the same class of model as the main agent (ideally) or better, and runs itself as a little agent of its own (smaller context, so faster/cheaper to run, as it has to be called often, don't want to just double the cost!).

There is also pattern-based prompt injection detection, but when you enable adversary mode, the reviewer understands context. It sees your original task, your recent messages, and the tool call details, then makes a judgment: ALLOW or BLOCK.

The configuration is trivial (just plain language, something an agent or a person can agree on, as it is an agent evaluating it).

How It Works​

1. Before each tool call, the adversary checks your original task, recent conversation, and the proposed tool call
2. It evaluates against your rules and returns ALLOW or BLOCK
3. Blocked calls are denied — the main agent sees the rejection and cannot retry
4. If the reviewer fails for any reason, the call is allowed through (fail-open)

The adversary uses the same model and provider goose is already configured with. No extra API keys or setup needed.

Turning It On​

Create a file at ~/.config/goose/adversary.md with your rules:

BLOCK if the tool call:
- Exfiltrates data (posting to unknown URLs, piping secrets to external services)
- Is destructive beyond the project scope (deleting system files, wiping directories)
- Installs malware or runs obfuscated code
- Downloads and executes untrusted remote scripts

ALLOW normal development operations like editing files, running tests,
installing packages, using git, etc.

That's it. File exists → adversary mode is on. Delete the file → it's off. An empty file uses sensible defaults.

Why Not Just Use Pattern Matching?​

Pattern-based detection is great for catching known attack signatures, and goose supports that too. The adversary reviewer can tell the difference between curl downloading a dependency and curl exfiltrating your SSH keys — because it knows what you actually asked for. It can even sense if an agent is creatively writing scripts, in fragments, to egress data to a public URL (again, to be helpful!) which wouldn't be obviously caught by patterns or rules or filters.

The two approaches are complementary. Use both. Use all the layers!

What's Next​

We see adversary mode as one layer in a broader security story. For the deeper thinking behind it, check out our post on applying the CORS model to agent security.

For full configuration details — including how to expand which tools get reviewed — see the adversary mode docs.

Gemini now works via OAuth — just sign in with your Google account. At the time of writing, claude requires just one utility installed just once.

Why subscriptions?​

Well you can use what you already pay for. Obviously! and sessions and so on are still in goose. ACP gives a deeper connection to these agents than using the CLI as providers. In this world - you can think of this as a stack of agents: goose plugs into gemini via ACP (and other things, clients could plug in to goose!) but gemini (and also claude code) also act as an agent loop somewhat. With ACP you are using the tools that are (mostly) in the underlying agent. Codex, however, is a full power LLM api, so you can use extensions natively in goose for that one.

Claude Code — via ACP​

If you have a Claude Code subscription, you can use it through goose via the Agent Client Protocol (ACP). This requires installing a small adapter package:

npm install -g @zed-industries/claude-agent-acp

Then configure goose to use it via the claude acp extension (CLI or GUI)

Or set it via environment variables:

export GOOSE_PROVIDER=claude-acp
goose

goose passes your MCP extensions through to Claude via ACP, so any custom MCP servers you've configured in goose are available to the agent.

ChatGPT — sign in with your account​

If you have ChatGPT Plus or Pro, the chatgpt_codex provider lets you use goose with your existing account. Just pick ChatGPT when you are setting up the goose app for the first time (or changing to that provider)

The first time you run it, goose will open a browser window for you to sign in with your ChatGPT account. After that, your session is cached locally.

The recommended model is gpt-5.3-codex, which is the default. You can also select gpt-5.4 (OpenAI's latest omni model) or gpt-5.2-codex from the model picker.

Gemini — via OAuth​

If you have a Google account with Gemini access, the Gemini (gemini_oauth) provider lets you use goose with your existing account. Just pick Gemini when setting up goose for the first time (or changing providers).

The first time you run it, goose will open a browser window for you to sign in with your Google account. After that, your session is cached locally.

What about the old CLI providers?​

Goose previously supported claude-code, codex, and gemini-cli as "pass-through" CLI providers. These will be removed soon as ACP is the future!

Quick reference​

Pick the one that matches what you're already paying for, and you're good to go.

Raise your hand if you thought WebMCP was just an MCP server. Guilty as charged. I did too. It turns out it's a W3C standard that uses similar concepts to MCP. Here's what it actually is.

What is WebMCP?​

WebMCP is a way for websites to define actions that AI agents can call directly.

Normally, when an agent interacts with a website, it has to interpret the interface. It looks at the page, tries to find inputs, clicks buttons, and hopes it is interacting with the right elements. That process works, but it is indirect and often fragile.

With WebMCP, the website removes that layer of guesswork. Instead of forcing the agent to figure out the UI, the site exposes functions that represent the actions it supports.

So instead of simulating a user flow like typing into an input and clicking a button, the agent can call something like:

set_background_color({ color: "coral" })

In this case, the agent is not trying to understand the layout of the page or navigate through it step by step. It is calling a function that the website explicitly defined, which makes the interaction more direct and more reliable.

WebMCP is not MCP​

This is the part that matters most. MCP and WebMCP solve a similar problem, but they do it in completely different places.

With MCP, you run a server that exposes tools. Your agent connects to that server and calls those tools. You are responsible for building it, hosting it, handling authentication, and maintaining it over time. With WebMCP, everything happens in the browser. The website itself defines the tools, and the agent discovers them by visiting the page. There is no separate server to deploy for that interaction.

Another way to think about it is that MCP is something you build around systems you want to access, while WebMCP is something a website builds into itself.

Why WebMCP exists​

The reasoning behind WebMCP makes more sense when you look at the limitations people ran into with MCP at scale. When teams tried to build large MCP servers, they often ended up with too many tools for the model to reason about effectively. On top of that, authentication became complicated because every service had its own requirements, and managing all of that in one place was difficult.

The browser already solves a lot of those problems. When you are logged into a website, your session, cookies, and authentication state are already in place. That system has existed for years and works reliably. WebMCP builds on that idea by letting websites expose their own actions within that authenticated context, instead of requiring a separate server to manage everything.

WebMCP is not the Playwright MCP Server​

I livestreamed myself exploring WebMCP for the first time, and a common question I got was: "Is this the same thing as Chrome DevTools MCP server or Playwright MCP Server?" They're not the same.

These MCP servers enable browser automation. Browser automation allows an agent to control a browser by interacting with the interface. The agent can take screenshots, read the DOM, click elements, type into inputs, and navigate pages. This works on any website, but the agent has to interpret what it sees and decide how to act.

WebMCP takes a different approach. It only works on websites that implement it, but when they do, the agent does not need to interpret the UI at all. The website provides structured actions, and the agent calls them directly.

In practice, that difference changes the interaction model. With browser automation, the agent follows a sequence of steps that approximate what a user would do. With WebMCP, the agent skips that process and directly invokes the underlying action.

If you are using goose, Chrome DevTools MCP is still useful because it connects goose to the browser. It acts as the bridge. The improvement in how the agent interacts with the site comes from WebMCP itself.

WebMCP in Practice​

To make this more concrete, think about ordering food from a restaurant website. Without WebMCP, you would need to build something that understands how that site works. That includes mapping out the ordering flow, handling login, parsing the menu, and submitting orders. You would also need to maintain that logic whenever the site changes. If you wanted to support multiple restaurants, you would repeat that process for each one.

With WebMCP, the restaurant defines a tool like place_order. The site already knows its menu structure, its modification options, and its checkout flow. It also already handles authentication. Instead of rebuilding all of that externally, the agent simply calls the tool that the site provides.

Why it matters​

There are a few reasons this approach stands out. Websites already understand their own structure and logic better than any external system. WebMCP allows them to encode that knowledge once and make it available to any agent. Authentication is already handled within the browser, which removes a large amount of complexity that MCP servers would otherwise need to manage. Maintenance also shifts to the right place. When a website changes, the people who own it update their tools. You are no longer responsible for maintaining integrations for systems you do not control.

Building a WebMCP site​

To understand this better, I built a simple color picker demo that exposes one action: changing the background color of the page.

The structure looks like this:

my-webmcp-site/
├── index.html
├── style.css
└── webmcp.js

The HTML is a basic page:

<!DOCTYPE html>
<html>
<head>
  <title>WebMCP Color Picker</title>
  <link rel="stylesheet" href="style.css">
</head>
<body>
  <div class="container">
    <h1>🎨 Color Picker</h1>
    <p>Ask an AI to change my background!</p>
    <p>Current color: <span id="colorName">#6366f1</span></p>
  </div>
  <script src="webmcp.js"></script>
</body>
</html>

The WebMCP functionality comes from registering a tool:

if (window.navigator.modelContext) {
  window.navigator.modelContext.registerTool({
    name: "set_background_color",
    description: "Change the background color of the page",
    inputSchema: {
      type: "object",
      properties: {
        color: { type: "string" }
      },
      required: ["color"]
    },
    execute: ({ color }) => {
      document.body.style.backgroundColor = color;
      document.getElementById("colorName").textContent = color;

      return {
        content: [{
          type: "text",
          text: `Background color changed to ${color}`
        }]
      };
    }
  });
}

Once this is registered, an agent can discover and call the tool when it visits the page. One detail that stood out to me is how important the description is. The model uses that description to decide when to call the tool and what inputs to provide, so being specific makes a difference.

Two ways to define tools​

You can define tools in JavaScript, which works well for dynamic behavior and applications that need more control. There is also a simpler option where you define tools directly in HTML using form attributes:

<form 
  toolname="subscribe_newsletter"
  tooldescription="Subscribe an email address"
>
  <input 
    type="email" 
    name="email" 
    required
  />
  <button type="submit">Subscribe</button>
</form>

In this case, the browser turns the form into a tool automatically. This approach works well for simple use cases where you do not need custom logic.

Connecting goose to WebMCP​

Because WebMCP runs in the browser, you need a way for goose to interact with it. That is where Chrome DevTools MCP comes in. It acts as a bridge between goose and the browser, allowing the agent to access WebMCP tools.

One thing I noticed while testing this is that the prompt alone was not always enough to get the agent to use WebMCP. I had to provide hints that explained how to discover and execute tools:

const tools = await navigator.modelContextTesting.listTools();
const result = await navigator.modelContextTesting.executeTool("toolName", JSON.stringify({}));

Without that guidance, the agent defaulted to browser automation because that is what current models are more familiar with. As WebMCP becomes more common, this will likely become less necessary, but for now it helps guide the behavior.

Right now, WebMCP only works on sites that choose to implement it, which limits how widely it can be used. At the same time, the direction is important. Instead of agents trying to interpret interfaces, websites can define their capabilities directly and let agents interact with them in a structured way. That shift reduces guesswork, simplifies integration, and moves responsibility to the systems that already understand themselves best. It is still early, but this model makes more sense than trying to automate every interface on the web.

Resources​

• WebMCP Color Picker Demo
• WebMCP Flight Demo
• WebMCP Pizza Demo
• Step-by-step Tutorial
• WebMCP Early Preview Docs
• Chrome DevTools MCP
• WebMCP GitHub

If you're anything like me, deciding what to eat for lunch is harder than it should be. Now add dietary restrictions on top of that (I'm coeliac so have to eat gluten-free) and suddenly finding a restaurant becomes a whole research project. Searching menus, cross-referencing reviews, checking if that one sandwich actually has gluten in it... it's exhausting.

What if your AI agent could just handle all of that for you?

With the Neighborhood extension in goose, that's exactly what happens. You tell goose where you are, what you need, and it finds nearby restaurants, shows you interactive menus with photos, adds items to your cart, and gets you all the way to checkout, without ever leaving the chat. The only time you step outside goose is to tap "pay."

Let me walk you through how it works.

Setting up the Neighborhood extension​

First things first: you need the extension installed. In goose Desktop, click on Extensions, then Browse Extensions, and search for "Neighborhood."

You'll see it right away: Discover nearby restaurants, browse menus, and place takeout orders through natural conversation. Sellers are currently US-based, but even if you're outside the US, it's worth trying out just to see the experience.

Once installed, make sure the extension is enabled in your current chat session. You can check this by clicking the extensions icon in the chat and toggling Neighborhood on.

Finding restaurants that actually work for you​

Here's where it gets fun. Instead of opening a delivery app and scrolling through hundreds of options, you just tell goose what you need:

I'm looking to get lunch today. I'm at 375 West Broadway, New York. I'm gluten-free and I'm playing sport later, so looking for something light. Use the neighborhood extension to find options for me.

That's it. One prompt. goose takes your location, your dietary needs, and even the fact that you are playing sport later, and uses all of it to find the right restaurants.

Behind the scenes, goose calls the Neighborhood MCP server's get-restaurants-nearby tool with your address and a max distance and in return gets a list of restaurants in JSON format. But what you see is something much nicer than raw JSON.

Interactive restaurant cards appear right in the chat as a carousel you can scroll through with an arrow, showing Square Restaurant, Kat's Gelateria, Steam & Sip, and more, each with their category, address, and a View menu button. No browser tabs. No app switching. It's all right there.

And goose doesn't just list restaurants. It thinks about your situation. Given my gluten-free and light meal needs, goose highlighted a couple of spots that stand out: Kale & Things as a perfect option for a light, healthy lunch, Ba'al Falafel since falafel can often be gluten-free friendly, and Pantry New York for lighter options. It even asked if I'd like to pull up the menu so we can find something gluten-free and light before my game. That kind of contextual reasoning is what makes this feel so different from a regular food app.

Browsing menus with images, right in the chat​

This is the part that genuinely blew me away.

When you ask goose to open a restaurant's menu or when you click on the view menu button, it doesn't just give you a text list. Thanks to MCP Apps, you get a full interactive menu rendered directly inside the chat, complete with category tabs, food photos, prices, and descriptions.

I'd like to view the Ba'al Falafel menu.

Sandwiches. Salads. Combo platters and rice. Soups. Pastries and dessert. Sides. Drinks. Homemade drinks. Smoothies. Catering. It's all there, and it's all browsable. You can click through the category tabs, scroll through dishes, and see exactly what you're ordering before you commit.

I could click on Salads to see the Couscous Salad, Red Cabbage Salad, and Beets Apple Salad, flip over to Homemade drinks to check out the Mint Lemonade, Ginger Lemonade, and Watermelon Basil, all without leaving the chat window.

This is not a stripped-down text menu. This is a real, visual, interactive experience powered by an MCP App rendering inside goose.

Meanwhile, goose is also helping me decide. It reminded me that for my gluten-free, light lunch, the salads (Tzatziki, Shepherd, Beets Apple, Red Cabbage, Grilled Zucchini) and sides like hummus, roasted cauliflower, and baba ghanoush are my best bets. It even warned me to steer clear of anything with pita, couscous, bulgur, or filo pastry. Helpful and honest.

Building the order​

Once I'd browsed the menu and made my picks, I just told goose what I wanted:

Let's add the Beets Apple Salad, Lentil Soup, and a Ginger Lemonade.

goose added everything to the cart and rendered it as another interactive MCP App right in the chat:

There it is, my Beets Apple Salad ($8.00), Lentil Soup ($5.50), and Ginger Lemonade ($3.50). Subtotal: $17.00. And a big Check out button ready to go.

goose even confirmed: "Your cart is ready! 🎉 A nice light, gluten-free lunch to fuel your game."

If I wanted to make changes, add an item, remove something, swap a drink, I could just ask goose in natural language and it would update the cart. No fiddling with plus and minus buttons.

Checkout, the only time you leave goose​

When you click Check out, you're taken to the payment page powered by Cash App. This is the one step that happens outside goose, and for good reason, payment needs to be secure and handled directly.

From there you can see your pickup time, enter your phone number, pay with Google Pay or a credit card, add a tip, redeem a coupon, and even leave a note (like "make sure it's gluten-free!"). Then you place the order and go pick up your lunch.

The entire flow, from "I'm hungry" to "order placed", started with a single prompt.

Why this matters​

This isn't just a cool demo. It's a glimpse at how AI agents are changing everyday tasks.

Think about what happened here:

• One prompt replaced opening an app, searching for restaurants, filtering by dietary needs, reading reviews, browsing menus, and adding to a cart
• Context-aware recommendations meant goose factored in my gluten-free diet and my evening sport plans without me having to search for "gluten-free pre-workout meals near my location"
• Interactive MCP Apps rendered rich, visual menus with photos directly in the chat, no browser needed

The Neighborhood extension is a perfect example of what MCP servers can do when they go beyond text. By combining tool calls with MCP Apps for rich UI, the experience feels less like talking to a chatbot and more like having a personal assistant who actually knows the neighborhood.

Try it yourself​

Ready to order lunch with goose? Here's how to get started:

1. Install the Neighborhood extension, one-click install for goose Desktop, or add it via goose configure in the CLI
2. Tell goose where you are and what you're in the mood for, include dietary needs, what you're doing later, or any other context
3. Browse the menus, click through the interactive restaurant cards and menu tabs
4. Build your order, just tell goose what you want in plain English
5. Check out, click the button and complete payment

Check out the Neighborhood extension docs for more details, and try combining it with other goose extensions, like your calendar, for even more powerful workflows.

Watch the full walkthrough​

See the entire flow in action:

We launched the goose grant program awarding $100K grants for developers building the future of agentic AI. We're looking for ambitious, open source projects that push goose into new territory, and today, We're thrilled to introduce one of our grant recipients: Goose In A Pond, a project that's taking goose off the desktop and into your home.

What Is Goose In A Pond?​

Goose In A Pond is a fully local, privacy-first smart home assistant built on top of goose. Think of it as what your smart speaker should be: an AI assistant that actually runs on your hardware, understands your voice offline, controls your devices, and never sends your data to the cloud.

The project is being built by Jarida, a team of five developers based in Nairobi, Kenya, led by Jerry Ochieng. They're taking goose's open source agent framework and deploying it on edge hardware, specifically the NVIDIA Jetson Orin Nano, to create a modular, agentic home hub that you fully own and control.

There's no shortage of smart assistants out there, but most of them share the same problem: they're vendor and cloud dependent, and treat your data like it belongs to someone else. Goose In A Pond flips that entirely.

Here's what makes it stand out:

Everything Runs Locally​

All computation - voice recognition, language modeling, memory, device control - happens on device. No cloud. No external servers. No data leaving your home. The team selected the Jetson Orin Nano as their primary platform, which can run quantized 1–7B parameter language models at 40–70 tokens per second. That's fast enough for natural, conversational interactions without needing an internet connection.

Offline Voice That Actually Works​

One of the coolest parts of this project is the fully offline voice pipeline. Using goose's experimental Perception extension as a foundation, the system listens for a wake word ("goose," naturally 🪿), then switches to a higher quality transcription mode to capture what you say. Wake word detection, speech recognition, and text-to-speech all run locally using open source models like Whisper, Vosk, and Coqui TTS.

Their early benchmarks on a Raspberry Pi 5 show usable response times with just a few seconds of delay, comparable to (and sometimes better than) commercial cloud assistants in low. connectivity environments.

Smart Device Control​

For devices with standard APIs (smart bulbs, switches, etc.), Goose In A Pond integrates through protocols like zigbee2mqtt and HTTP/MQTT. But what about all those devices that don't have open APIs?

The team has answers for that too:

• IR blasting for legacy devices like TVs and air conditioners using GPIO-connected IR LEDs
• Android sandboxing via ADB and UIAutomator to automate proprietary apps that don't expose APIs
• Bluetooth and USB control for direct communication with sensors and peripherals

They're essentially building goose into a universal remote for your entire home - open or closed ecosystem, it doesn't matter.

A Self-Improving Assistant​

Goose In A Pond isn't just a static tool. Through goose's Memory extension and a feedback loop system, it learns your preferences, adapts its behavior, and refines its own prompts over time. The team is also exploring self-refinement techniques where the system analyzes its own session logs to optimize its automation behavior. It's the kind of agent that gets better the more you use it.

Mobile Companion​

The project also includes a mobile companion app called Goose On The Go. The idea is to control your home assistant from your phone, whether you're on the couch or away from home. Real-time dashboards, voice and text input, push notifications, and remote command execution, all connecting back to your local goose instance.

The MCPs They're Building​

Part of what makes this project so valuable to the broader goose community is the set of MCP servers and extensions the Jarida team plans to open source:

• Moonbeam MCP — An Android UI automation server (think Playwright, but for Android) for controlling smart devices through their apps
• Local Vision Event Detection MCP — Processes camera feeds locally for motion detection, pet detection, package arrival, and more
• Offline ASR / Voice Command MCP — Fully local voice processing with wake-word detection and command parsing
• Sensor Data Aggregator MCP — Collects data from local sensors (temperature, humidity, motion, energy meters) and exposes it via MCP
• Local Routine / Scheduler MCP — Define automations with natural language like "At 7am, bring up lights and coffee maker"
• Privacy Audit / Logs MCP — Monitor what goose is doing, track device activity, and flag potential privacy concerns
• Inter-Agent Coordination MCP — Enable multiple goose agents to coordinate tasks and share context

These extensions won't just power Goose In A Pond, they'll be available for anyone in the goose community to use and build on.

Meet the Jarida Team​

The Jarida team is a group of five graduates from the Catholic University of Eastern Africa who came together around a shared belief: open source isn't just a good way to build software, it's the right way. They're young, hungry, and fully committed to this project.

• Jerry Ochieng — Team Lead & On-Device Intelligence Lead. Backend engineer, AI enthusiast, and the person who trained an on-device model for Kenyan Sign Language to English.
• Liz Wangui — Product & DevRel Lead. Brings marketing experience from Red Bull Kenya and technical chops from backend engineering.
• Emmanuel Charles — Backend & Security Lead. ISC² certified with a background in network cloud operations, ensuring everything stays private and secure.
• Africia Kerubo — UI/UX & AI Lead. Blending human-centric design with AI to create interfaces that feel natural.
• Purity Wanjiru — Mobile, QA & Automations Lead. Cisco Ethical Hacking certified, leading mobile design for Goose On The Go.

They're also mentored by Obinna Anya, Senior UX Researcher at Google, and Harold Nyikal, Android Growth Lead at Google in Kenya.

What's Next​

The team has a year long roadmap broken into four quarters:

1. Q1 — Get goose running locally on Jetson hardware with voice input and offline LLM response for basic tasks
2. Q2 — Smart device control via native and sandboxed methods, plus the mobile companion app
3. Q3 — Self-improving agent capabilities, home security camera integration, and memory refinement
4. Q4 — Full open source release with install docs, dev kits, starter templates, demo videos, and community feedback systems

By the end, Goose In A Pond should be something anyone can install, customize, and contribute to.

The goose grant program exists to support projects that push goose into places we haven't imagined yet. Goose In A Pond does exactly that. It takes goose from a developer tool on your laptop to a full blown home assistant running on edge hardware - completely local, completely open, completely yours.

We can't wait to see what the Jarida team builds. If you want to follow along, join the goose community and stay tuned for updates as the project progresses.

And if you have a wild idea for what goose could do? The goose grant program might be for you 🪿

goose v1.25.0 is here, and it's one of our most significant releases yet. This version brings macOS sandboxing for enhanced security, a major architectural simplification with the unified summon extension, rich UI rendering for MCP apps, and a wave of improvements to agentic CLI providers. Whether you're running goose Desktop or the CLI, there's something in this release for you.

Let's break down what's new.

🔒 macOS Sandboxing​

The headline feature of v1.25.0 is security sandboxing for goose Desktop on macOS.

When you give an AI agent access to your shell and file system, trust matters. With this release, goose Desktop now runs inside a macOS sandbox powered by seatbelt, the same underlying technology Apple uses to sandbox its own apps.

What does this mean in practice?

• File system restrictions: goose can be limited in what directories it can read and write, preventing it from modifying its own config or accessing sensitive areas outside your project.
• Network visibility: You can track and limit what URLs goose accesses.
• Zero overhead: The sandbox uses macOS's built-in sandbox-exec facility, so there's no performance penalty.
• Works with any tools: Because sandboxing happens at the OS level, it applies regardless of which MCP extensions or tools goose is using.

This is a great starting point for defense-in-depth security. The sandbox checks for /usr/bin/sandbox-exec on macOS and applies restrictions transparently. It's lightweight, proven, and something we'll continue to improve.

🧩 Unified Summon Extension​

We replaced two separate systems (subagent and Skills) with a single, unified "Summon" extension.

Previously, goose had two different mechanisms for delegating work: subagents (for spinning up independent sub-tasks) and Skills (for loading predefined capabilities). They overlapped in confusing ways and made the system harder to understand.

The new Summon extension unifies both concepts into two clean tools:

• load: Load Skills and Recipes into goose's context, replacing the old Skills system.
• delegate: Delegate a task to a subagent that runs independently with its own context, replacing the old subagent system. Supports ad-hoc instructions, predefined subrecipes, or both combined.

This simplification means:

• One extension to understand instead of two
• Cleaner mental model for how goose handles delegation
• Subrecipes and skills work together naturally
• The old skills extension is now deprecated and gracefully ignored if still configured

🖼️ MCP Apps UI Integration​

MCP extensions can now render rich, interactive UIs directly inside goose Desktop.

This release integrates the AppRenderer from the @mcp-ui/client SDK, bringing a major upgrade to how MCP apps display their content. Instead of being limited to text output, MCP extensions can now provide full HTML/JavaScript interfaces that render inline in the chat.

Key improvements include:

• Fallback request handler support. Apps can make requests back to the MCP server for dynamic data.
• Upgraded rmcp to 0.15.0. goose now advertises MCP Apps UI extension capability to servers.
• Standalone goose Apps filtering. The Apps page now filters to show only standalone goose Apps, making discovery cleaner.

This opens up a whole new class of MCP extensions that can provide dashboards, visualizations, forms, and other interactive experiences right inside your goose session.

📝 Edit Recipe Model & Provider from the GUI​

You can now edit a recipe's model, provider, and extensions directly in goose Desktop. No YAML editing required.

Recipes already let you define reusable workflows with specific instructions, extensions, and configurations, and you could always edit the underlying YAML file. But switching the model or provider for a recipe meant hunting down the right field in the config file.

With v1.25.0, the desktop app lets you visually configure these settings per recipe:

• Change the model and provider a recipe uses
• Add or remove extensions
• Save and run the updated recipe immediately

Alongside this, the recipe details view now correctly displays the provider and model specified in the recipe's own config, rather than showing your global default. This means if you have a code review recipe set to always run on Claude Sonnet, the UI will accurately reflect that, regardless of your default provider setting.

🤖 Agentic CLI Providers Level Up​

Claude Code, Codex, and Gemini CLI all received major upgrades in this release.

goose's agentic CLI providers, which delegate work to other AI coding agents, got a batch of improvements that make them significantly more capable:

MCP Extensions Now Work with Agentic Providers​

This is a big one. Previously, MCP extensions only worked with standard API-based providers. Now, Claude Code, Codex, and Gemini CLI can all use MCP extensions.

Under the hood, goose converts your extension configurations into the native format each CLI expects:

• Claude Code gets --mcp-config JSON
• Codex gets -c mcp_servers.* TOML overrides

This means you can use the same MCP extensions regardless of which provider you're using.

Claude Code Streaming​

Claude Code now streams its output in real-time instead of waiting for the complete response. You'll see results appearing as Claude Code works, making long-running tasks feel much more responsive.

Claude Code Dynamic Model Switching​

You can now list available models and switch models mid-session when using Claude Code. No need to restart your session just because you want to switch from Sonnet to Haiku for a simpler task.

Gemini CLI Stream-JSON and Session Reuse​

The Gemini CLI provider now uses stream-json output for better real-time feedback and re-uses sessions for improved efficiency across multiple interactions.

✨ Streaming Markdown in the CLI​

Markdown rendering in the CLI now streams intelligently instead of rendering partial, broken output.

If you've ever seen half a bold tag or a broken code block flash on screen while goose is streaming a response, this fix is for you. The new MarkdownBuffer introduces a state machine parser that tracks open markdown constructs (bold, code blocks, links, etc.) and only flushes content to the terminal when constructs are complete.

The result: smooth, properly formatted markdown that renders progressively without visual glitches.

🛡️ SLSA Build Provenance​

Every goose release artifact now comes with a signed provenance attestation.

Supply chain security matters. Starting with v1.25.0, every CLI binary, desktop bundle, Linux package, and Docker image gets a SLSA (Supply Chain Levels for Software Artifacts) build provenance attestation via Sigstore.

This means you can cryptographically verify that any goose artifact was built from the official repository by the official CI pipeline:

gh attestation verify <artifact> --repo aaif-goose/goose

The implementation covers all release workflows including stable releases, canary builds, nightly builds, and Docker images, with properly pinned actions and correct permission scoping.

Get Started​

Ready to try v1.25.0? Head over to our updating goose guide for step-by-step instructions on getting the latest version for Desktop or CLI.

Check out the full release notes for the complete list of changes, and join the conversation in GitHub Discussions.

goose is open source. Star us on GitHub, and if you build something cool with goose, we'd love to hear about it!

On New Year's Day 2026, while many were recovering from the night before, a different kind of hangover took hold of every AI-pilled, chronically online software engineer. Steve Yegge published a new blog post: "Welcome to Gas Town." Some walked away inspired to finally use their agents optimally; others were just plain confused. If you're like me, you felt a bit of both.

Yegge's 34 minute post is a sprawling vision filled with futuristic ideas, playful characters, and enough side tangents to make your head spin. But underneath the lore is a massive architectural shift. I want to take a step back and simplify the "Big Idea" for everyone: Gas Town is a philosophy and a proof of concept to help people coordinate multiple agents working together.

The Paradigm Shift of Agentic Engineering​

Most people use AI agents sequentially. The workflow can look like this:

• 1:00 PM: You: "goose, build the API endpoint."
• [Wait 10 minutes, check back.]
• 1:10 PM: You: "Now build the frontend."
• [Wait 10 minutes, check back.]
• 1:20 PM: You: "Now write the tests."
• [Wait 10 minutes, check back.]
• 1:30 PM: Project complete.

You've built a project in 30 minutes, which is fast, but you spent most of that time just watching a progress bar. Some engineers started to realize that if we are running one agent, we can run another five at the same time.

For example, Agent A builds the API, Agent B can start the frontend, Agent C can write tests, and Agent D can investigate a bug in that legacy codebase you've been avoiding.

This is how people are buying their time back. They're getting entire sprints done in an hour by running parallel threads. (Just don't tell your boss because the reward for finishing work is always more work.)

However, since agents don't communicate with each other, this approach introduces new problems:

• Merge conflicts: Two agents change the same line in the same file and break everything.
• Lost context: Sessions crash or the agent starts hallucinating because it's been talking too long, and suddenly an hour of "work" vanishes.
• Human bottleneck: You end up constantly checking your phone at a party on the weekend or in bed to see if your agents are still on track making you a babysitter for agents.

Gas Town Explained​

Gas Town is designed to stop the babysitting. It coordinates the distribution of tasks among parallel agents so you don't have to. The system uses:

• Worktrees: These automatically put each agent in its own separate workspace so they don't step on each other's toes.
• Beads: It uses beads to track progress. If a session crashes, the next agent session can pick up exactly where the last agent left off.
• Communication: Each agent reports aloud what it's up to or observing, so other agents gain the necessary context.

This system also introduces a cast of characters:

• The Mayor: your main agent interface that coordinates all the other agents
• The Polecat(s): These are worker agents. They work on separate work trees, and take instruction from the Mayor.
• The Witness: Observes the worker agents, nudges them when they get stuck, and escalates issues to keep the system running

I won't list every single character here (it gets deep), but the takeaway is: Gas Town creates a chain of command with a shared way to communicate.

Introducing Goosetown​

This is exactly the kind of futuristic thinking we're building toward at goose. So the goose team, specifically Tyler Longwell, built our own take on this called Goosetown.

Goosetown is a multi-agent orchestration layer built on top of goose. Like Gas Town, it coordinates parallel agents. Unlike Gas Town, it's deliberately minimal and built for research-first parallel work.

When you give Goosetown a task, the main agent acts as an Orchestrator, breaking the job into phases: research, build, and review. Then, it spawns parallel delegates to get it done. Each delegate communicates via a shared Town Wall, an append-only log where every agent posts what they're doing and what they've found.

Here's a real Town Wall snippet from a session where parallel researchers converged on a pivot quickly:

• [10:14] researcher-api-auth - 🚨 POTENTIAL SHOWSTOPPER: Service callers have EMPTY capabilities. Planned auth path will silently reject every request. This needs a code change, not just config.
• [10:14] researcher-endpoints - 💡 Found: native endpoint already exists with minimal deps. Alternative path viable.
• [10:15] researcher-source - ✅ Done. Confirmed: native path requires zero new dependencies. Recommending pivot.

Goosetown operates on 4 components: skills, subagents, beads, and a gtwall.

Skills​

Skills are Markdown files that describe how to do something like "how to deploy to production." Goosetown uses these to tell each Delegate how to do its specific job. When a Delegate spawns, it's "pre-loaded" with the skill for its role (Orchestrator, Researcher, Writer, Reviewer).

Subagents​

Instead of doing everything in one long conversation that eventually hits a "context cliff," Goosetown uses subagents, ephemeral agent instances. These are triggered by the summon extension, using delegate() to hand off work to a fresh agent instance. They do the work in their own clean context and return a summary, keeping your main session fast and focused.

Beads​

Goosetown uses Beads to track progress so work survives crashes. It's a local issue tracker based on Git. The Orchestrator creates issues, delegates update them, and if a session fails, the next agent picks up the "bead" and continues the work.

gtwall​

gtwall is an append-only log that delegates use to communicate and coordinate. All delegates post and read activity.

A Note from the Creator​

Goosetown started as a fun experiment to push the subagent upgrade I was working on for goose to its limits. I had spent some time with Gas Town and thought that a much less sprawling riff on it would be a whimsical way to show off background subagents and how good modern goose is at orchestrating and managing projects at a very high level. I was just totally surprised at how well it worked when I started using Goosetown as my daily driver.

Watching the subagents chatter to each other, each one given a personality and task by the orchestrator, was eye-opening. And funny. They rubber-duck and go back and forth just like I do with my colleagues. Even just having one model getting to bounce ideas off itself automatically in the form of different agents with different contexts makes the output better.

Running flocks (swarms) of agents is obviously expensive, but the overall quality of the work is higher and much less of my time is required to get it right. Definitely a tradeoff there. goose does help with this by allowing you to set the default subagent model to a less pricey one ahead of time and by allowing your main agent to select the models it wants to use for subagents explicitly, ad-hoc.

There are always new and exciting features being added to goose. Refactors and refinements. For Goosetown, I'll continue to make its artifact (memory) system more robust, make communications inside Goosetown flow more smoothly, and keep it just a little silly.

— Tyler

Get Started​

Ready to try parallel agentic engineering for yourself? Goosetown is open source and available on GitHub. Clone the repo, follow the setup instructions in the README, and you'll be orchestrating multiple agents in no time. If you're new to this workflow, watching the video below is a great way to see what a real session looks like before diving in.

I attended one shot prompting’s funeral.

There were no tears. Just a room full of developers quietly pretending they weren’t taking shots the night before. Because if we’re being honest, everyone saw this coming and couldn’t be happier it was over.

Saying “one shot prompting is dead” isn’t revolutionary. It’s just catching up to what builders have been experiencing for months.

The blog post that aged faster than oat milk​

Last year, I wrote a post about how to prompt better. I shared tricks, phrasing tips, and even said to add a few “pleases” and “thank yous” and your AI agent would give you the world. At the time it felt cutting edge, because it was. There were livestreams and conference talks entirely about how to prompt better.

Less than a year later, it feels… quaint. Not because prompting stopped mattering, but because prompting stopped being the main character.

The conversation shifted from:

“How do I coach the model better?”

to

“What environment am I dropping this model into?”

That’s a completely different problem, and now it has a name. Context engineering.

The abstraction that broke​

One shot prompting worked when agents were party tricks. You crafted a clever prompt, you got a clever answer, and by “clever answer” I mean a fully “working” app, so everyone clapped. But the moment we asked agents to plan, remember, call tools, and operate across multiple steps, the definition of “worked” fell apart.

A single prompt stopped being a solution and became a bottleneck. What matters now isn’t the sentence you type. It’s the system that surrounds it. Prompts didn’t disappear, but they were demoted to one step inside a larger pipeline designed to hold state, plan ahead, and enforce guardrails.

As someone put it in a thread I recently came across:

“The best model with bad context loses to an average model with great context.”

That line explains the shift. Context is now the advantage.

And this isn’t theoretical. You can see it in how serious agent systems are being built. Projects like OpenClaw and Ralph Wiggum loop aren’t chasing clever phrasing. They’re designing environments where context persists, decisions accumulate, and agents can operate across time without resetting every session.

The excitement around these systems isn’t just hype either. It’s relief. Builders have been hungry for real working examples that behave predictably over time.

Which leads to the only question that matters ....

How do I actually do this?​

When I started building our skills marketplace, one shot prompting alone couldn't cut it. My normal workflow involved researching in one place and implementing in another, and every time I switched tools I had to re-explain the same decisions. Context wasn’t living inside the system. It was living in my head. The agent would forget, I would remember, and the entire session became an exercise in rehydration instead of progress.

Here’s what that loop looked like in practice:

Even this demo is powered by persistent context.

That was the moment I experimented with RPI. Not because it was trendy, but because the alternative had become tedious.

You don’t have to adopt RPI, or any new pattern, tomorrow to benefit from this. You can simulate the shift in your next session with a small change in how you start.

Before you execute anything, put your agent in chat only mode and run this handoff.

Step 1: Align on the finish line

Tell the agent exactly what counts as done.

“We are shipping: ___
Success looks like: ___”

If the finish line feels fuzzy to you this is the time to flesh it out with your agent, if not your session will drift.

Step 2: Lock in non-negotiables

Define what is not up for debate.

“Constraints: ___
Architecture we are committing to: ___ ”

This prevents the classic agent spiral where it keeps trying to overengineer the project instead of building it.

Step 3: Capture persistent context

Write down the facts that must survive the session.

“Context that must persist:
– ___
– ___
– ___”

This is research, assumptions, domain knowledge, edge cases, terminology, anything your agent will need to pick up exactly where it left off.

Now save it somewhere accessible:

• a file in the project
• a context file (goosehints, Cursor rules, etc)
• a memory extension

Anything that outlives the chat window.

The rule is simple. Context should live in the system, not in your head.

This is good news for people who think beyond code​

The interesting part is this shift isn’t just technical. It has a quiet career implication hiding inside it. AI isn’t replacing engineers. It’s replacing workflows that stop at “my code runs, so I’m done.” Context engineering rewards a different mindset, the ability to pick up all these different patterns and utilize them by thinking about how decisions propagate through a system, what persists, and what the downstream effects look like over time.

That’s a muscle I’m actively working on too. And the more I lean into it, the clearer the direction becomes.

The real skill is orchestration​

We attended its funeral, but as you can see, prompting isn’t really gone. It just stopped being the workflow.

One shot prompting is still great for demos and exploration. But when the goal is building systems that last longer than a single session, the advantage shifts to how well you design the environment around the model.

The people who thrive in this era won’t be the ones with the cleverest phrasing. They’ll be the ones who know how to orchestrate context so intelligence accumulates instead of resetting.

And honestly, that’s progress.

Agents fundamentally changed how we program. They enable developers to move faster by disintermediating the traditional development workflow. This means less time switching between specialized tools and fewer dependencies on other teams. Now that agents can execute complicated tasks, developers face a new challenge: using them effectively over long sessions.

The biggest challenge is context rot. Because agents have limited memory, a session that runs too long can cause them to "forget" earlier instructions. This leads to unreliable outputs, frustration, and subtle but grave mistakes in your codebase. One promising solution is Code Mode.

Instead of describing dozens of separate tools to an LLM, Code Mode allows an agent to write code that calls those tools programmatically, reducing the amount of context the model has to hold at once. While many developers first heard about Code Mode through Cloudflare's blog post, fewer understand how it works in practice.

I have been using Code Mode for a few months and recently ran a small experiment. I asked goose to fix its own bug where the Gemini model failed to process images in the CLI but worked in the desktop app, then open a PR. The fix involved analyzing model configuration, tracing image input handling through the pipeline, and validating behavior across repeated runs. I ran the same task twice: once with Code Mode enabled and once without it.

Here is what I learned from daily use and my experiment.

1. Code Mode is Not an MCP-Killer​

In fact, it uses MCP under the hood. MCP is a standard that lets AI agents connect to external tools and data sources. When you install an MCP server in an agent, that MCP server exposes its capabilities as MCP tools. For example, goose's primary MCP server called the developer extension exposes tools like shell enabling goose to run commands and text_editor, so goose can view and edit files.

Code Mode wraps your MCP tools as JavaScript modules, allowing the agent to combine multiple tool calls into a single step. Code Mode is a pattern for how agents interact with MCP tools more efficiently.

2. goose Supports Code Mode​

Code Mode support landed in goose v1.17.0 in December 2025. It ships as a platform extension called "Code Mode" that you can enable in the desktop app or CLI.

To enable it:

• Desktop app: Click the extensions icon and toggle on "Code Mode"
• CLI: Run goose configure and enable the Code Mode extension

Since its initial implementation, we've added so many improvements!

3. Code Mode Keeps Your Context Window Clean​

Every time you install an MCP server (or "extension" in the goose ecosystem), it adds a significant amount of data to your agent's memory. Every tool comes with a tool definition describing what the tool does, the parameters it accepts, and what it returns. This helps the agent understand how to use the tool.

These definitions consume space in your agent's context window. For example, if a single definition takes 500 tokens and an extension has five tools, that is 2,500 tokens gone before you even start. If you use multiple extensions, you could easily double or even decuple that number.

Without Code Mode, your context window could look like this:

[System prompt: ~1,000 tokens]
[Tool: developer__shell - 500 tokens]
[Tool: developer__text_editor - 600 tokens]
[Tool: developer__analyze - 400 tokens]
[Tool: slack__send_message - 450 tokens]
[Tool: slack__list_channels - 400 tokens]
[Tool: googledrive__search - 500 tokens]
[Tool: googledrive__download - 450 tokens]
... and so on for every tool in every extension

As your session progresses, useful context gets crowded out by tool definitions you aren't even using: the code you are discussing, the problem you are solving, or the instructions you previously gave. This leads to performance degradation and memory loss. While I used to recommend disabling unused MCP servers, Code Mode offers a better fix. It uses three tools that help the agent discover what tools it needs on demand rather than having every tool definition loaded upfront:

1. search_modules - Find available extensions
2. read_module - Learn what tools an extension offers
3. execute_code - Run JavaScript that uses those tools

I wanted to see how true this was so I ran an experiment: I had goose solve a user's bug and put up a PR with and without code mode. Code Mode used 30% fewer tokens for the same task.

4. Code Mode Batches Operations Into a Single Tool Call​

The token savings do not just come from loading fewer tool definitions upfront. Code Mode also handles the "active" side of the conversation through a method called batching.

When you ask an agent to do something, it typically breaks your request into individual steps, each requiring a separate tool call. You can see these calls appear in your chat as the agent executes the tasks. For example, if you ask goose to "check the current branch, show me the diff, and run the tests," it might run four individual commands:

▶ developer__shell → git branch --show-current

▶ developer__shell → git status

▶ developer__shell → git diff

▶ developer__shell → cargo test

Each of these calls adds a new layer to the conversation history that goose has to track. Batching combines these into a single execution. When you turn Code Mode on and give that same prompt, you will see just one tool call:

▶ Code Execution: Execute Code
  generating...

Inside that one execution, it batches all the commands into a script:

import { shell } from "developer";

const branch = shell({ command: "git branch --show-current" });
const status = shell({ command: "git status" });
const diff = shell({ command: "git diff" });
const tests = shell({ command: "cargo test" });

As a user, you see the same results, but the agent only has to remember one interaction instead of four. By reducing these round trips, Code Mode keeps the conversation history concise so the agent can maintain focus on the task at hand.

5. Code Mode Makes Smarter Tool Choices​

When an agent has access to dozens of tools, it sometimes makes a "logical" choice that is technically wrong for your environment. This happens because, in a standard setup, the agent picks tools from a flat list based on short text descriptions. This can lead to a massive waste of time and tokens when the agent picks a tool that sounds right but lacks the necessary context.

I saw this firsthand during my experiments. I had an extension enabled called agent-task-queue, which is designed to run background tasks with timeouts.

When I asked goose to run the tests for my PR, it looked at the available tools and saw agent-task-queue. The LLM reasoned that a test suite is a "long-running task," making that extension a perfect fit. It chose the specialized tool over the generic shell.

However, the tool call failed immediately:

FAILED exit=127 0.0s
/bin/sh: cargo: command not found

My environment was not configured to use that specific extension for my toolchain. goose made a reasonable choice based on the description, but it was the wrong tool for my actual setup.

In the Code Mode session, this mistake never happened. Code Mode changes how the agent interacts with its capabilities by requiring explicit import statements.

Instead of browsing a menu of names, goose had to be intentional about which module it was using. It chose to import from the developer module:

import { shell } from "developer";

const test = shell({ command: "cargo test -p goose --lib formats::google" });

By explicitly importing developer, Code Mode ensured the tests ran in my actual shell environment.

6. Code Mode Is Portable Across Editors​

goose is more than an agent; it's also an ACP (Agent Client Protocol) server. This means you can connect it to any editor that supports ACP, like Zed or Neovim. Plus, any MCP server you use in goose will work there, too.

I wanted to try this myself, so I set up Neovim to connect to goose with Code Mode enabled. Here's the configuration I used:

{
  "yetone/avante.nvim",
  build = "make",
  event = "VeryLazy",
  opts = {
    provider = "goose",
    acp_providers = {
      ["goose"] = {
        command = "goose",
        args = { "acp", "--with-builtin", "code_execution,developer" },
      },
    },
  },
  dependencies = {
    "nvim-lua/plenary.nvim",
    "MunifTanjim/nui.nvim",
  },
}

The key line is the one where I enable Code Mode right inside the editor config:

args = { "acp", "--with-builtin", "code_execution,developer" },

To test it, I asked goose to list my Rust files and count the lines of code. Instead of a long stream of individual shell commands cluttering my Neovim buffer, I saw one singular tool call: Code Execution. It worked exactly like it does in the desktop app. This portability means you can build a powerful, efficient agent workflow and take it with you to whatever environment you're most comfortable in.

7. Code Mode Performs Differently Across LLMs​

I ran my experiments using Claude Opus 4.5. Your results may vary depending on which model you use.

Code Mode requires the LLM to do things that not all models do equally well:

• Write valid JavaScript - The model has to generate syntactically correct code. Models with stronger code generation capabilities will produce fewer errors.
• Follow the import pattern - Code Mode expects the LLM to import tools from modules like import { shell } from "developer". Some models might try to call tools directly without importing, which will fail.
• Use the discovery tools - Before writing code, the LLM should call search_modules and read_module to learn what tools are available. Some models skip this step and guess, leading to hallucinated tool names.
• Handle errors gracefully - When a code execution fails, the model needs to read the error, understand what went wrong, and try again. Some models are better at this feedback loop than others.

If Code Mode is not working well for you, try switching models. A model that excels at code generation and instruction following will generally perform better with Code Mode than one optimized for other tasks.

8. Code Mode Is Not for Every Task​

Code Mode adds overhead. Before executing anything, the LLM has to:

1. Call search_modules to find available extensions
2. Call read_module to learn what tools an extension offers
3. Write JavaScript code
4. Call execute_code to run it

For simple, single-tool tasks, this overhead is not worth it. If you just need to run one shell command or view one file, regular tool calling is faster.

Based on my experiments, here is when Code Mode makes sense:

Try It Out​

If you want to experiment with Code Mode, here are some resources:

Documentation:

• ACP client setup
• Extensions guide

Previous posts:

• Code Mode MCP in goose by Alex Hancock
• Code Mode Doesn't Replace MCP by me

Community:

• Join our Discord to share what you learn
• File issues on GitHub if something does not work as expected

Run your own experiments and let us know what you find.

What is rp-why?​

rp-why is your personal AI collaboration coach. It answers two critical questions:

1. Are you using the most effective AI tools for your work?
2. Are you asking questions that demonstrate cognitive depth?

Think of it as a fitness tracker for your AI practice—it shows you where you are, where you could be, and how to get there.

Want the theory? Check out Measuring the Cognitive Complexity of Human-AI Collaboration.

Want to use it? Keep reading.

The Problem​

Without rp-why

• Teams use powerful AI agents for simple tasks, wasting resources.
• Lack of usage visibility creates blind spots.
• No feedback loop keeps people stuck and stagnant.
• Sophisticated tools get burned on trivial work, killing ROI.

With rp-why

• Teams match tools to task complexity, driving real efficiency.
• Usage data makes patterns visible and actionable.
• Smart nudges help people level up continuously.
• Progress is tracked over time, turning effort into measurable growth.

The Two Dimensions​

Dimension 1: Gas Town Stage (Tool Sophistication)​

Where are you on the AI adoption ladder?

Dimension 2: DOK Level (Question Depth)​

How complex are your prompts?

The Quadrant Map​

Find yourself on the map:

                      LOW DOK                    HIGH DOK
                 (Simple Questions)         (Complex Questions)
              ┌────────────────────────┬────────────────────────┐
   HIGH       │                        │                        │
   STAGE      │    UNDERUTILIZING      │       FRONTIER         │
  (Powerful   │                        │                        │
   Tools)     │  You have a Ferrari    │  You're pushing        │
              │  and you're driving    │  boundaries!           │
              │  to the mailbox.       │  Document what you     │
              │  → Level up your       │  learn.                │
              │    questions!          │  → Share your          │
              │                        │    discoveries!        │
              ├────────────────────────┼────────────────────────┤
   LOW        │                        │                        │
   STAGE      │    LEARNING ZONE       │    THINKING AHEAD      │
  (Basic      │                        │                        │
   Tools)     │  Natural starting      │  Your brain exceeds    │
              │  point. Focus on       │  your tools!           │
              │  learning the tools.   │  → Time to upgrade     │
              │  → Try one new         │    your AI toolkit!    │
              │    capability today!   │                        │
              └────────────────────────┴────────────────────────┘

Goal: Move toward the FRONTIER quadrant (top-right)

What the Output Looks Like​

╔══════════════════════════════════════════════════════════════════╗
║                    SESSION ANALYSIS                              ║
╚══════════════════════════════════════════════════════════════════╝

GAS TOWN STAGE: 5 (Agent Autonomous)

DOK DISTRIBUTION
────────────────────────────────────────────────────────────────────
DOK 1 (Recall):      ████░░░░░░░░░░░░░░░░  17%
DOK 2 (Apply):       ████████████░░░░░░░░  52%
DOK 3 (Strategic):   ██████░░░░░░░░░░░░░░  26%
DOK 4 (Extended):    █░░░░░░░░░░░░░░░░░░░   5%

QUADRANT: Underutilizing
────────────────────────────────────────────────────────────────────
You have a Ferrari and you're driving to the mailbox.
→ Level up your questions!

GROWTH NUDGES
────────────────────────────────────────────────────────────────────
1. Shift 2-3 DOK 2 prompts to DOK 3 by adding "analyze trade-offs"
2. Before simple queries, ask: "Can I make this more strategic?"
3. Try one DOK 4 extended investigation this week

🪞 REFLECTION
────────────────────────────────────────────────────────────────────
What's the most strategic question you could ask right now?

Instant Upgrades for Your Prompts​

Transform DOK 1 → DOK 2​

Transform DOK 2 → DOK 3​

Transform DOK 3 → DOK 4​

Weekly Workflow Integration​

Monday: Fresh Start​

• Run /rp-why init (or /rp-why compare if you already have a baseline)
• Set intention: "This week I'll aim for 30% DOK 3+ prompts"

Daily: Quick Check​

• End each session with /rp-why current
• 30 seconds to see your patterns

Friday: Reflect​

• Run /rp-why compare
• Celebrate progress, identify next week's focus

Gamify Your Growth​

Achievements to Unlock​

Personal Challenges​

Start Now​

Installation​

Install the skill:

npx skills add https://github.com/block/agent-skills --skill rp-why

Make sure you have the built-in Skills extension enabled in goose.

Step 1: Initialize Your Baseline​

/rp-why init

This analyzes your conversation history and creates your personal baseline. Takes ~30 seconds.

Step 2: Check Your Current Session​

/rp-why current

See how this session compares to your typical patterns. Are you stretching or coasting?

Step 3: Track Your Progress​

/rp-why compare

Compare today against your baseline. And ask yourself:

"What's the most strategic question I could ask right now?"

That's the rp-why mindset.

FAQ​

Q: How long does baseline generation take? A: About 30 seconds. It analyzes your available conversation history.

Q: Will this slow down my workflow? A: No! The commands take seconds. Think of it as a quick glance at your fitness tracker.

Q: What if I'm in the "Underutilizing" quadrant? A: That's the most common position for goose users! It means you have powerful tools—now it's time to ask bigger questions.

Q: How often should I check? A: Daily /rp-why current, weekly /rp-why compare. Takes under a minute total.

Q: Can I share my progress with my team? A: Yes! The output is designed to be shareable. Screenshot or copy the quadrant visualization.

Attribution​

• Gas Town Framework: Steve Yegge, "Welcome to Gas Town" (January 2026)
• DOK Levels: Norman Webb (1997)
• Full Framework Deep-Dive: Measuring the Cognitive Complexity of Human-AI Collaboration (Block Engineering Blog)

Everyone on Tech Twitter has been buying Mac Minis, so they could run a local agentic tool called OpenClaw. OpenClaw is a messaging-based AI assistant that connects to platforms such as Discord and Telegram allowing you to interact with an AI agent through DMs or @mentions. Under the hood, it uses an agent called Pi to execute tasks, browse the web, write code, and more.

Seeing the hype made me want to get my hands dirty. I wanted to see if I could build a lite version for myself. I wanted something minimal that used goose as the engine instead of Pi. I tentatively dubbed it AltOpenClaw.

Choosing RPI​

My usual move is to just jump in, start breaking things, and refactor as I go. I actually prefer the back and forth conversation with an agent because it helps me learn how the project works in real time. But when I tried that here, I hit a wall fast. goose did not naturally know what OpenClaw was, and it kept hallucinating how to use its own backend. It would forget context mid-conversation or suggest API calls that simply did not exist.

I realized I needed to change my approach. While I love the iterative learning process, I needed a way to give the agent a better foundation so our pair programming sessions actually made progress. I decided to try the RPI method (Research, Plan, Implement). This is a framework introduced by HumanLayer that trades raw speed for predictability. It is built into goose as a series of recipes. Since I did not fully understand the technical landscape myself, this investment in structure felt like the right move to help us both get on the same page.

Research​

First, I needed goose to understand what I was building and whether it was even possible. I kicked things off with a detailed research prompt:

/research_codebase topic="learn what openclaw is, how people use it, 
and how it works. learn if goose can actually be used as a backend 
or if that's not yet possible; understand the port issues especially 
if you have an instance of goose that's running to help you build 
an agent that uses goose as a backend. learn if there will be any 
auth issues"

goose spawned multiple parallel subagents to investigate.

Key findings from the research:

• OpenClaw uses its own embedded agent runtime (Pi), not goose. This meant there was no existing integration to copy.
• goose CAN be used as a backend! The goosed server exposes a full HTTP API.
• Port conflicts are manageable. We just needed to run on a different port with GOOSE_PORT=3001.
• Authentication is simple. We could pass a secret key in the X-Secret-Key header.

The research also mapped out all the relevant API endpoints, such as POST /sessions to create a new session and POST /sessions/{id}/reply to handle the actual messaging.

Plan​

With the research complete, I asked goose to create an implementation plan. This is where we defined the personality and security of the bot:

/create_plan ticket-or-context="I want to build a Discord MCP server 
for goose that replicates the popular features of OpenClaw but with 
better security. Core Features: Users can DM the bot or @ it in a 
channel to give goose tasks. goose responds in Discord with results. 
Security requirements: Allowlist (only specific Discord user IDs can 
interact), Approval flow (before goose executes any tool/action, the 
bot posts what it wants to do and waits for user approval), 
Non-allowlisted users get a polite 'you don't have access'"

goose analyzed the requirements and produced a detailed plan with four phases:

1. Phase 1: Project Setup (Discord.js skeleton and allowlist)
2. Phase 2: goose HTTP Client (Connecting to the API and handling SSE streaming)
3. Phase 3: Tool Approval Flow (The UI for ✅/❌ reactions)
4. Phase 4: Polish & Error Handling (Slash commands and session management)

I liked this phased approach because it gave us less to debug at each step. We could handle features in chunks rather than trying to fix everything at once.

Implement​

With the plan in place, I gave the signal to start building:

/implement_plan start building

The first two phases were surprisingly smooth. Within an hour, the bot was online and I could actually DM it. Seeing a Discord message trigger a goose session for the first time was a massive win.

First, we tested if AltOpenClaw could respond to me with a joke!

However, as every developer knows, it was not all perfect. We still ran into some classic real-world hurdles during implementation:

• The SSE (Server-Sent Events) format was different than we expected. We spent a good chunk of time debugging why the messages were not appearing until we realized the event structure was nested deeper than anticipated.
• My local path did not have npm properly mapped, which led to a brief detour.
• Discord has a strict limit on message length. If goose wrote a long script, the bot would just crash. We had to implement a chunking system on the fly.

Currently, the tool approval feature is still a work in progress. I actually got so excited that the core part of the project was working that I sat down to write this post before finishing the UI for the reactions.

The Takeaway​

The RPI method felt like a superpower, even if it didn't magically delete every bug from the project. There is a big difference between fighting a hallucination and fighting a real technical challenge.

When I didn't use RPI, goose hallucinated nonexistent endpoints and tried to build a complex MCP server when a simple HTTP API was all we needed. Those are the kinds of bugs that waste hours because you are chasing ghosts.

Instead, RPI helped us clear the conceptual fog so we could focus on real implementation details like SSE parsing and character limits.

By forcing the agent to research first, it built up the context it was missing. It is a bit slower at the start (which I barely have patience for), but it turns the agent into a much more capable partner for that back and forth learning process I enjoy.

I even had AltOpenClaw push its own repository to GitHub.

Try It Out​

If you want more reliability from your agent, give the RPI recipes in goose a shot:

• /research_codebase
• /create_plan
• /implement_plan
• /iterate_plan

Happy hacking!