Skip to content

FAQ · SESSIONS

Working in sessions

I sent messages while the chat was starting — are they lost?

No. Every message the composer accepts goes into that chat's queue, including messages sent before the session is ready, and the queue dispatches them in order once it is. Since v0.6.3 a message sent while a chat is still starting is no longer stranded, and a failed send stays first in the queue so it can be retried or edited.

Why this comes up: A new chat takes a moment to start its harness. People type into the pause, see nothing happen, and assume the messages went into the void. Older builds did sometimes strand them.

What to do:

  1. Wait. The queue resumes the moment the session is ready, in acceptance order, even if you have moved to another chat.
  2. Look for the queued messages under the composer. Each can be edited in place or dismissed; editing keeps its position, and dismissing one does not send the next.
  3. If a queued message fails, the app says so and offers retry or edit. Nothing is sent twice: a message leaves the queue only when the session has begun processing it.
  4. Dismiss a message you no longer want rather than sending "ignore that", which is just another queued turn.

Why it matters: The queue lets you keep thinking while the agent works, and only helps if you trust it. Accepted means queued, queued means it will go, and one message never becomes two turns. See Queue, steer and dispatch.

What does Steer do, and why is it unavailable?

Steer pushes the first queued message into the turn that is already running, instead of waiting for it to finish. It is Goose-only, it applies only to the first message in the queue, and its shortcut — Enter with an empty composer while the agent is working — does nothing while you have draft text or are editing a queued message.

Why this comes up: Three different things make the control disappear or fail, and the app does not always say which. Steering is also not stopping: a steered message changes the agent's course mid-turn.

What to do:

  1. Check the harness. In Settings → behavior, follow-up behaviour offers queue or steer, and steer is labelled Goose harness only.
  2. Check the composer: empty, with no queued message under edit. Cmd+Enter (Ctrl+Enter elsewhere) sends immediately and does the opposite of your default for one message.
  3. If you see Steering is not available in this Goose backend, the Coach cannot resolve it from source: the message refers to "the steering backend branch," developer language, and whether every public Goose build supports steering is not verified. Queue instead, or stop generation and resend.
  4. A steered message is labelled Steered in the transcript, so you can see where the course changed.

Why it matters: Steering is the difference between correcting an agent now and after five minutes and a provider bill spent going the wrong way. See Queue, steer and dispatch.

What happens when the conversation is compacted?

Older context is summarised to free the context window and your token count resets. The transcript you see does not change — the app says Conversation compacted. Older context was summarized — but from then on the model sees the summary, not the original turns. Auto-compaction is Goose-only, fires at a threshold set in Settings → behavior, and is off at 100%. A Compact toolbar action does it on demand.

Why this comes up: Compaction is invisible until an agent forgets something it knew ten minutes ago. A rarer notice about verification reads as though the chat is broken when it is not.

What to do:

  1. Watch the context usage indicator in the toolbar: tokens against the limit, and session cost where reported. When it is high, decide before the app does.
  2. Before a compaction, put anything the agent must keep into a file or the project description, where it survives summarisation.
  3. If you see Couldn't verify the compacted conversation, your messages are still shown; reload the session as the notice suggests. Since v0.6.1 an incomplete reload preserves the transcript.
  4. For long work, fork the session from a message rather than letting one conversation carry everything.

Why it matters: A summarised agent still has the file and the project, not the wording of what you said an hour ago. How session cost is computed is not documented; treat it as an indicator, not an invoice. See Context, compaction and cost.

Where did my files and changes go?

Almost always into one of three places the right rail shows for this chat: the attached workspaces, the changes view (git status and diff for them), or the artifacts view (files opened from the conversation). A chat with no workspace attached — a general chat — saves generated files to the artifact location set in the system section of Settings, and the rail shows that folder.

Why this comes up: The rail is scoped to this session's attachments, not the project, so a file can be visible in one chat and absent from another. And the viewer follows the disk: a file moved or deleted outside Berd disappears from it too.

What to do:

  1. Read the rail's workspace list first; if the folder you expect is not there, the chat never had it.
  2. Code: the changes view. Generated documents: the artifacts view. Greyed-out artifact actions mean the file was deleted on disk; they return if it reappears.
  3. General chat: look in the artifact location from Settings.
  4. Removing an ordinary workspace keeps files on disk. Removing a Goose-created worktree deletes it, uncommitted changes included, and the confirmation says so. Read it.
  5. A chat reporting a missing folder has loaded with a fallback path; edit the project to fix it.

Why it matters: The one irreversible move is removing a managed worktree with uncommitted work in it. Everything else is looking in the right scope. See Attach workspaces and use the right rail.

Can I switch model mid-chat?

Yes, from the model picker in the chat toolbar, and the conversation carries on; Berd's own tour says "even mid-chat". Recent models sit near the top. If a switch fails, the chat keeps its previous model and says which.

Why this comes up: People expect switching to mean starting over, as chat assistants elsewhere do. Here the conversation belongs to the session, not the model, so a strong model for the hard step and a cheap one for the tidy-up is normal.

What to do:

  1. Switch when the task changes character; trying costs nothing. See Connect a provider and pick a model.
  2. Expect the behaviour to change even though the history does not; a different model reads the same context differently.
  3. One documented exception: a chat whose earlier reasoning came from a Claude model may refuse to continue on Claude later, with a notice to start a new chat or switch to a non-Claude model.
  4. Model is not harness. The harness is chosen per session and the sources describe no way to change it in place; whether that is possible without a new chat is not verified.

Why it matters: Not marrying a vendor is a stated reason for Berd to exist, and only real if used. Brad, Block's AI lead, on On The Block: if a model is 98% as good at half the cost, "we can just swap the whole fleet." See Model vs. harness.

Yes, and since v0.6.3 across every session, not only those already loaded. Cmd+K opens search across chats, projects, skills, agents and settings; Session History has its own search covering titles, agents, projects and dates and — from two characters — the conversation text, with a toggle to include archived sessions.

Why this comes up: Three keys do three different things, and the sidebar shows only recent chats. Someone looking for a conversation from a month ago sees a short list and concludes the rest is gone.

What to do:

  1. Cmd+K for anything by name; Cmd+P to jump between sessions by fuzzy title; Cmd+F to find text in the open conversation. All three are rebindable in Settings → shortcuts.
  2. For content, open Session History (the sidebar offers View all chats whenever more exist), type at least two characters, and read the status line: it says whether results include conversation text or only metadata.
  3. Switch on the Archived toggle if the chat may have been auto-archived; the rules live in Settings → archive.
  4. "Conversations could not be read" means excluded from text search, not deleted.
  5. Sending a message to an archived chat restores it (since v0.6.4).

Why it matters: The value of a private workspace is that nothing is lost, and search keeps that promise. It also marks what Berd is not: a conversation is a file on one laptop, searchable by you alone. See Keep sessions in order and Keyboard shortcuts.

An app in the chat wants to send a message as me — should I let it?

Only if the exact text in the confirmation is something you would type yourself. Since v0.6.4 an MCP App rendered inline in a chat cannot submit a message as you without a confirmation that names the extension and tool asking, shows the full text, and waits for send or cancel. That dialog is the only gate.

Why this comes up: An MCP App is interactive content inside the transcript — a form, a picker, a small tool — and some complete an action by sending a chat message. Before v0.6.4 that could happen silently, under your name, and the agent would act on it.

What to do:

  1. Read the dialog in full. It says which extension and tool want to send the message as you, and shows the text. If you did not just do something in that app, cancel.
  2. Check that the named extension is one you configured (or, on a distribution with company-managed connections, one your organisation manages); Settings → connections lists them.
  3. Once sent, the message is yours: your turn in the transcript, an instruction to the agent.
  4. Report an app that keeps asking without cause like any Berd problem; see Keep Berd current and report problems.

Why it matters: This is the rule Berdy's own instructions set — anything sent on your behalf is shown word for word and needs your explicit go-ahead — extended to third-party apps. It only works if you read rather than click through. See Work with artifacts and MCP apps.

Last checked: Berd v0.6.4, 2026-09-11.

Reference

Verified
Berd v0.6.4 · 2026-09-11
NEVER BESTUCK AGAINCLICK ME

Guide built with Berd, Claude and Codex · verified against Berd v0.6.4, 2026-09-11 · read from source, not yet tested in the app · Buzz Guide · About · not affiliated with Block