Does Goose Remember Between Sessions? Sessions, Hints, and the Memory Extension
Does Goose Remember Between Sessions? Sessions, Hints, and the Memory Extension Short answer: a Goose session can be resumed, and Goose ships several mechanisms that carry information forward — but none of them is automatic, shared memory. What persists between sessions depends on which of Goose's four memory mechanisms you actually set up, and each one has a boundary where the remembering stops. The four ways Goose carries information forward Goose, Block's open-source AI agent, treats "mem
Does Goose Remember Between Sessions? Sessions, Hints, and the Memory Extension
Short answer: a Goose session can be resumed, and Goose ships several mechanisms that carry information forward — but none of them is automatic, shared memory. What persists between sessions depends on which of Goose's four memory mechanisms you actually set up, and each one has a boundary where the remembering stops.
The four ways Goose carries information forward
Goose, Block's open-source AI agent, treats "memory" as a set of distinct features rather than one system:
1. Resumable sessions. Goose organizes work into sessions, and sessions persist. You can close a session, come back days later, resume it by name, and continue with the accumulated context intact rather than starting cold. This is the closest thing to "remembering," and it works well for long-running tasks.
2. The memory extension. Goose ships with an optional memory extension whose job is persisting context across sessions — coding conventions, project facts, preferences you want every future session to know. It is a real cross-session store, not just replay.
3. .goosehints. These are hint files Goose loads at session start (including nested ones it discovers as it explores your project). They act as standing instructions: how this repo is organized, which commands are safe, what conventions to follow.
4. Persistent instructions (MOIM). Goose's Model-Observed Internal Memory component injects text into the model's working memory on every turn. You configure it with the GOOSE_MOIM_MESSAGE_TEXT or GOOSE_MOIM_MESSAGE_FILE environment variables, and it is re-read fresh each interaction — so guardrails cannot be "forgotten" as a conversation grows. Content is capped at 64 KB.
On paper, that is a thorough kit. In practice, operators hit the same wall with each mechanism: it only remembers what was explicitly put there.
What actually persists — and where it stops
A resumed session remembers its own conversation, not you. Resuming a named session replays that session's accumulated context. Start a new session tomorrow for a different task and it knows nothing about yesterday's work unless the memory extension captured the relevant facts. Sessions are continuations, not a shared knowledge base. For automation runs that spin up fresh sessions per job — the headless batch tasks Goose is often used for — every run begins as a stranger.
The memory extension is opt-in and local. It only knows what was stored into it, it lives on the machine where Goose runs, and a second install on another machine has its own separate memory. There is no sync, no shared store, no "my laptop's Goose and my server's Goose know the same things." Two installs drift apart exactly the way two notebooks do.
.goosehints are instructions, not memory. A hint file tells Goose how to behave; it does not update itself based on what Goose learned. If your deployment process changes, the hint file is stale until a human edits it. Operators who treat hints as memory end up with confident, outdated instructions loaded into every session — the static-file version of the stale-wiki problem.
Persistent instructions have a 64 KB ceiling. That is plenty for guardrails ("never force-push to main") but it is a small slot, and everything persistent competes for it. It is a place for rules, not for the growing body of what your automations have learned.
Desktop and CLI do not remember equally. Goose's own documentation notes the asymmetry: the desktop app carries persistent memory across sessions, while a CLI session starts fresh. Since scheduled and headless automation runs through the CLI, the exact use case where memory matters most — unattended runs — is the one that starts blank.
The pattern operators settle on
None of this is a flaw in Goose specifically; it is the honest shape of local-first agent memory. The operators who run Goose successfully in automation treat its mechanisms as layers with clear jobs: sessions for task continuity, the memory extension for per-machine conventions, hints for static project rules, persistent instructions for guardrails. And they accept the boundary: nothing here follows the operator across machines, and nothing captures what happened automatically.
When the automation grows past one machine — Goose on the laptop, Goose on the VPS, a chat assistant on the phone — that boundary becomes the whole problem. The fix is a hosted memory layer underneath the agents: one memory, reachable from every tool over MCP, that records full conversation history automatically instead of relying on each session's notes, hints, and extensions staying in sync.
That is what Vilix AI provides. It is cloud-hosted with zero infrastructure to manage, so there is nothing to install per machine. The same memory follows you everywhere over MCP: every agent reads and writes one shared store instead of keeping separate local memories. It keeps full conversation history, not just distilled facts, so what actually happened in a run is there without anyone writing it down. It is free forever, with a 7-day Pro trial that needs no credit card, and you can export or delete everything anytime.
Goose remembers what you told it to remember, where you told it. Give your agents one memory that is not tied to a single machine, and the next session stops being a stranger.
Get Started for Free — free forever, no credit card.