I’ve edited this post, but AI helped. These are meant to be quick posts for the Advent of AI. If I’m doing one of these each day, I don’t have time to spend a couple hours on each post.

The advent of AI series leverages Goose, an open source AI agent. If you’ve never heard of it, check it out!

block / goose

an open source, extensible AI agent that goes beyond code suggestions - install, execute, edit, and test with any LLM

goose

a local, extensible, open source AI agent that automates engineering tasks

goose is your on-machine AI agent, capable of automating complex development tasks from start to finish. More than just code suggestions, goose can build entire projects from scratch, write and execute code, debug failures, orchestrate workflows, and interact with external APIs - autonomously.

Whether you’re prototyping an idea, refining existing code, or managing intricate engineering pipelines, goose adapts to your workflow and executes tasks with precision.

Designed for maximum flexibility, goose works with any LLM and supports multi-model configuration to optimize performance and cost, seamlessly integrates with MCP servers, and is available as both a desktop app as well as CLI - making it the ultimate AI assistant for developers who want to move faster and focus on innovation.

Quick Links

• Quickstart
• Installation
• Tutorials
• Documentation
• Responsible AI-Assisted Coding Guide
• Governance

Need Help?

• Diagnostics & Reporting
• Known Issues

…

The Challenge: Terminal Integration

Advent of AI day 13 is about integrating Goose directly into your terminal. I tried it for the first time today, and honestly, it confused me at first. I’m used to agent CLIs like Aider, Claude Code, or Goose’s own REPL where you enter a session, have a back-and-forth conversation, and then exit when you’re done.

Terminal integration with @goose works differently. It took me a bit to understand what it’s actually for.

What I Expected vs What I Got

When I first ran @goose "help me with this", I expected it to drop me into a conversational session. Instead, it answered my question and... that was it. Back to my normal terminal prompt. No active session indicator, no "you are now talking to Goose" feedback.

I thought "okay, so it’s just a fancy way to ask one-off questions?" That seemed useful but not revolutionary. The terminal integration docs mentioned persistent sessions, but it wasn’t obvious how that worked in practice.

The Difference: Ambient vs Active

Here’s what I figured out. Terminal integration is a fundamentally different model than traditional agent CLIs:

Traditional Agent CLIs (Aider, Claude Code, Goose REPL)

• You enter a session
• Back-and-forth conversation
• Blocking - you’re "in it" until you exit
• When you’re done, you exit
• Session ends

Terminal Integration (@goose)

• No explicit session entry/exit
• You work normally in your terminal
• Call @goose when you need it
• It responds, then you continue your normal work
• Session persists in the background
• Call it again whenever - could be 5 seconds later, could be 5 minutes later
• Has full context from the session when you do

The key insight: it’s ambient assistance rather than active pairing.

You don’t have to commit to "I’m working with an AI now." You just work normally, and when you need help, it’s there. No context switch, no blocking conversation, no "am I done with this session?" decision.

Setting It Up

The setup is straightforward. Add this to your shell config:

# For zsh (add to ~/.zshrc)
eval "$(goose term init zsh)"

Note: The assumption is you’ve installed the goose CLI. If you haven’t, run curl -fsSL https://github.com/block/goose/releases/download/stable/download_cli.sh | bash

Restart your terminal or source the config, and you’re done. The docs cover bash, fish, and PowerShell too.

I’m using Ghostty on macOS, but this works with any terminal emulator.

How It Actually Works

Each terminal window gets its own Goose session that lasts until you close that window. When you run @goose (or @g for short), you’re continuing an ongoing conversation in that specific terminal.

Here’s a real example from today. I was working on Day 13’s Festival Staff Scheduling project and needed to continue implementing a PRD:

❯ @goose "continue with the PRD. We were at data organization. Continue implementing the beginner phase, /Users/nicktaylor/dev/advent-of-ai-2025/day-13/PRD-Festival-Staff-Scheduling.md"

─── text_editor | developer ──────────────────────────
path: ~/d/a/day-13/PRD-Festival-Staff-Scheduling.md
command: view

Now let me check what's already been done in the project:
─── shell | developer ──────────────────────────
command: cd /Users/nicktaylor/dev/advent-of-ai-2025/day-13 && find . -type f -name "*.json" ...

─── text_editor | developer ──────────────────────────
path: ~/dev/advent-of-ai-2025/day-13/staff_data.json
command: view

Great! I can see you've already completed the data organization step. The staff data has been structured into a comprehensive JSON format. Now let's continue with **Section 1.3: Basic Website (HTML/CSS)** from the Beginner Phase.

Goose opened the PRD, checked what was already done, and told me the next step. All from one command. No session management, no explaining context.

The Sudo Use Case

Here’s where this model really makes sense. I’ve run into this problem a bunch with other agent CLIs: the agent needs to install something system-wide but can’t run sudo. So you have to:

1. Pause the agent
2. Open a new terminal
3. Run the sudo command
4. Go back to the agent
5. Tell it you’re done and it should continue

With terminal integration:

❯ @goose "install this package globally"
# Goose: "You need to run: sudo npm install -g whatever"
❯ sudo npm install -g whatever
# You run it with your privileges
❯ @goose "okay continue"
# Goose sees you ran the command, knows it succeeded, continues

Everything stays in one terminal. Goose sees what you did. No context loss, no explaining what happened.

This works for any scenario where you need to do something the agent can’t:

• Authentication flows (entering passwords)
• Interactive prompts from CLI tools
• Manual verification steps
• Privileged operations (Docker, system config)

Monitoring Your Session

You can add context indicators to your shell prompt to see how full your session is:

# Add to ~/.zshrc
PROMPT='$(goose term info) %~ $ '

Your prompt will show something like:

●●○○○ sonnet ~/projects $

The dots show context usage (five dots total), and you see which model is active. When you hit ●●●●●, responses slow down and you should start a fresh session with eval "$(goose term init zsh)".

Named Sessions for Long-Running Work

By default, each terminal gets its own session that disappears when you close it. For longer work, you can use named sessions:

eval "$(goose term init zsh --name my-project)"

Named sessions persist across terminal restarts and can be shared between windows. You can close your terminal, come back later, run the same command, and continue where you left off.

Still Figuring This Out

I’m new to Goose and I’m still understanding when terminal integration makes sense versus using the full REPL. The ambient assistance model works well for:

• Working on a project with occasional questions
• Tasks that need manual intervention (sudo, authentication)
• Long sessions where you’re switching between coding and asking for help

But I’m not sure it replaces the conversational flow of traditional agent CLIs for deep pair programming sessions. That’s something I’ll figure out as I use it more.

If you want to try this yourself, check out the terminal integration guide. And the full Day 13 challenge has more ideas.

If you want to stay in touch, all my socials are on nickyt.online.

Until the next one!

Photo by Amit Talwar on Unsplash