Goose forgets the middle of a long session. Its memory belongs in a vault

Goose is built to run long. Hand it a task, let it work, come back later. The consequence most people meet a few weeks in is that a long session cannot keep everything it saw. At eighty percent of the token limit Goose compacts the conversation into a summary and carries on, and the detail that got summarised is detail the agent no longer holds. The work survives. The reasoning behind it usually does not, and neither does anything a second person would have wanted to read.

Why does a long Goose session end with less than it learned?

Three mechanisms, all of them deliberate, all of them good engineering.

Compaction. Goose's docs say auto-compaction fires by default at 80% of the token limit, in both the Desktop app and the CLI. You can move the trigger with GOOSE_AUTO_COMPACT_THRESHOLD, disable it entirely by setting it to 0.0, or run /compact yourself before you reach the ceiling. What it does is replace older turns with a summary. The earlier conversation stays visible in the session, but only the compacted version goes into the active context. Summaries keep conclusions. They drop the three approaches that were tried and abandoned, which is usually the part worth having.

Subagents. Goose can spawn subagents that work in their own isolated sessions so the main conversation does not fill with tool output. By default everything a subagent did is reported back to the main session, and you can ask for a summary only. Either way, the detailed working happened somewhere you were not reading, and it ends when that subagent ends.

The session store. Since version 1.10.0 Goose keeps sessions in a SQLite database at ~/.local/share/goose/sessions/sessions.db, and goose session --resume --name my-project picks one back up. That is genuine persistence and it is worth knowing about. It is also one database, on one laptop, holding raw transcripts. Nobody on your team is going to open it, and nothing in it is a thing a person can correct when it turns out to be wrong.

None of this is a flaw to route around. It is what lets a session run for hours at all. The fix is not to make the agent remember more. It is to have it write the parts worth keeping into a place that was never part of the session.

What does Goose already have for memory, and where does each one stop?

Two features, and both are better than most agents ship.

.goosehints is a plain text file, global at ~/.config/goose/.goosehints and local at the root of a project or in directories below it. It loads at the start of a session and goes into the system prompt, which means you pay for it on every request. Goose's own documentation says to keep it concise for exactly that reason. That advice is correct, and it is also the ceiling: a file that is read in full every single time cannot be where a team's accumulated context goes.

The Memory extension is the dynamic version. It stores and retrieves on demand through remember_memory, retrieve_memories, remove_memory_category and remove_specific_memory, with memories saved as files on disk, local in .goose/memory/ or global in ~/.config/goose/memory/. Goose loads saved memories at the start of a session and includes them in the prompt. It is a real answer to a real problem.

It is also scoped to one machine and one home directory. The colleague who needs the same fact tomorrow cannot reach it, cannot fix it when it goes stale, and will have their own copy that says something slightly different. The agent remembers. The team still does not, which is the same wall Cline's memory bank hits from the other direction.

What is Baalda, in one paragraph?

Baalda is a team second brain made of ordinary markdown files on your own disk. Several people can edit the same note at the same time over a CRDT, access is set per folder and per note, and the core is open source under Apache-2.0 and can be self-hosted. It serves the vault over MCP at /api/mcp, so an agent reads and writes the same files a person does, under that person's permissions rather than a shared service account. Running it locally is free, with an optional managed Team plan if you want hosted sync. If the category is unfamiliar, what a team second brain is covers the idea before any of the setup.

Worth noting that Goose and Baalda arrive from the same place. Goose is Apache-2.0, written in Rust, built at Block and since contributed to the Linux Foundation's Agentic AI Foundation, with the repository now under the aaif-goose organisation. Neither side of this setup is something you have to ask permission to run.

How do I add Baalda to Goose as an extension?

Goose calls MCP servers extensions. Baalda is a remote one.

1. Mint a token. In Baalda, open Vault settings and then MCP, and create a token. It is shown once, starts with mcp_, and carries both the user and the vault it belongs to. Everyone mints their own. That is the entire permission model: the agent inherits your access, not a wider one.

2. Run `goose configure`. Choose Add Extension, then Remote Extension (Streamable HTTP). It asks what to call the extension, then for the Streamable HTTP endpoint URI, which is https://api.baalda.com/api/mcp for the hosted service or your own host plus the same /api/mcp path if you self-host. Running the desktop server on your own machine it is http://localhost:3010/api/mcp. Next it asks for a timeout, defaulting to 300 seconds, and a description. When it asks whether you would like to add custom headers, say yes and add one: Authorization with the value Bearer mcp_your_token_here.

3. Or write it yourself. The same thing in ~/.config/goose/config.yaml, which on Windows lives under your roaming app data instead:

extensions:
  baalda:
    type: streamable_http
    name: baalda
    enabled: true
    uri: "https://api.baalda.com/api/mcp"
    headers:
      Authorization: "Bearer mcp_your_token_here"
    env_keys: []
    envs: {}
    timeout: 300

In the Desktop app the same entry goes in through Extensions and Add custom extension. Restart Goose afterwards either way.

One thing not to do: the endpoint will also take the token as a ?key= query parameter. It works, and it is worse. URLs end up in logs and shell history in a way headers do not.

Why is the transport an easy decision here?

Because Goose has already made it for you. Its documentation says the supported extension types are builtin, platform, stdio and streamable_http, that SSE is not supported, and that old SSE configurations should be migrated.

That happens to line up exactly with how Baalda works. There is no server-initiated stream to subscribe to: GET /api/mcp and DELETE /api/mcp both return 405 on purpose, so a client can tell immediately that every message goes over POST and nothing is waiting on an open channel. In other clients this is the line that breaks the connection, because their default is the legacy transport and you have to override it. In Goose there is no wrong option to pick.

What can Goose do once it is connected, and what stops it doing damage?

The vault arrives as tools, not as a folder: list_folders, list_notes, read_note, search_notes, create_note, update_note, append_note, edit_note, move_note, delete_note, plus list_attachments and read_attachment_text for files that are not markdown. search_notes reaches into attached documents and spreadsheets too, and each hit says whether it came from a note or a file.

Two of these matter more than the rest when an agent is working unattended for an hour.

read_note returns a revision. Pass it back as expectedRevision on a write and the write is refused if the note moved in the meantime, rather than silently landing on top of whatever changed. For a long autonomous run this is the difference between an agent that notices a teammate edited the file and one that does not.

edit_note works on anchors, and each anchor has to match exactly once. An anchor that matches zero times, or more than once, fails the whole call and writes nothing. Partial edits do not happen.

Underneath both, every call goes through the same per-folder and per-note permissions as the person whose token it is. A folder you cannot open is a folder Goose cannot read, and there is no flag that widens it. If you want to narrow it further, Goose's extension config has an available_tools field for filtering which tools an extension exposes, so you can start read-only and add the writes once you trust the setup.

Do subagents get the vault too?

Yes. Goose's documentation says subagents inherit all extensions from the main session by default, and that you can restrict what they reach for security, focus or performance. It also says subagents cannot enable, disable or modify extensions, so one cannot quietly grant itself more than the parent session had.

That combination is the useful part. A subagent sent off to investigate something can read the vault for prior context and write its finding back, and that write survives the subagent, survives the compaction of the main session, and survives the session ending. The isolation that normally means the work evaporates stops meaning that, because the output has somewhere to go that is not the transcript.

What is actually worth writing down during a run?

Not the transcript. A log of everything is a log nobody reads.

What earns its place is the small set of things that will be re-derived otherwise: the decision and the reason for it, the approach that was tried and failed and why, the constraint discovered halfway through that was not in any ticket, and the state of a long task at the point you stopped. Those are the things compaction eats first, because a summary keeps outcomes and drops the path.

The practical shape is one instruction in .goosehints telling Goose to write findings into a specific folder in the vault as it goes, rather than at the end. At the end is after compaction. As it goes is before.

And because the destination is markdown on disk that renders in a normal editor, the person who reads it next can fix it. That is the part a memory/ directory on one laptop cannot do, and it is the same reason the files have to stay files rather than becoming rows in a store only the agent queries.

Where is this the wrong setup?

If you are one person running Goose on one machine, the Memory extension and a short .goosehints are already the right size. Adding a remote extension to that is a moving part with nothing to show for it. Use what ships.

Obsidian deserves a fair mention too. Its plugin ecosystem is far larger than ours, community MCP servers for it exist and work, and for a single person it is excellent software. What it does not do is several people editing the same note at once, or permissions below the level of the whole vault, which is the specific gap the multiplayer post goes through in detail. If your situation is really one person plus a sync subscription, stay where you are.

Baalda is also the wrong answer if you want database views and typed properties, or if plain files you can read without the app are not something you would pay anything to keep. It is the right one when a long autonomous run produces conclusions that other people need, when the agent should be held to the same access as the person who started it, and when what the agent learned at 2pm should still be true, and still correctable, next month.