The terminal learns where one command ends, and can be dragged wider

"The last command and its output" was not something the panel could honestly
offer. sendToChat took the last forty rows of the screen buffer, hard-wrapped at
the terminal's width with no way to tell a wrap from a newline -- its own comment
said so. So bash and zsh are given the OSC 133 markers VS Code and WezTerm use,
and Copy, Send and an Auto toggle are built on those.

The integration is written by the PTY command string itself, with printf. sshd
runs that string through $SHELL -c, so it can case on the shell's own name and
needs no probe, no second channel and no writable home. Passing it through the
environment does not work -- every distribution ships AcceptEnv LANG LC_*, so
anything else is dropped silently -- and feeding `source ...` in as keystrokes
races a slow .zshrc, echoes into the scrollback and lands in shell history.

Nothing needs hiding, which is the point of choosing it: the setup runs before
the shell exists and never writes to the PTY's input side, so there is nothing
to echo and no fan-out gate to build.

Two things were wrong in the first version and both were found by running it
against real shells rather than the fake one. bash: the DEBUG trap fires before
every simple command *including each one inside PROMPT_COMMAND*, so $? read from
there is whatever ran a moment ago -- every command reported success. The status
is captured in the trap now, which also removes the two-entry PROMPT_COMMAND
dance entirely. zsh: $ZDOTDIR is already ours by the time .zshenv runs, so the
shims were sourcing themselves and none of the user's configuration loaded; the
original is passed on the exec line.

Parsing is server-side. The `behind` path resets the terminal and replays a
truncated scrollback, so a client parser routinely sees a finish with no start;
two tabs share one shell and can disagree; and what comes out of this ends up
inside a prompt, so deriving it here leaves nothing to disbelieve. The bytes are
fanned out unchanged -- xterm consumes an OSC it has no handler for.

Output is bounded head and tail, 48KB and 16KB: a build that fails ten megabytes
in has the invocation at the top and the error at the bottom. Carriage returns
collapse to the last state of each line, which is the difference between a
usable prompt and two megabytes of spinner. The fence is sized to its content,
because output containing three backticks would otherwise break out and read as
prose.

Any shell that is not bash or zsh starts exactly as it did before. The buttons
then scrape the screen and say so, and Auto is disabled rather than degraded:
forty arbitrary lines on every message is worse than nothing.

Also a generic [data-resize] handle, keyboard included, persisted the way the
theme is. The inspector and sidebar can have it whenever they want it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

README.md

@@ -46,6 +46,13 @@ runtime. Clone it, `pip install -e .`, run it.
 - **Attachments** — drag, paste or pick images, PDFs and text files. Images are
   downscaled and sent to vision models; PDF and text content is extracted and
   put in the prompt
+- **`@` to name something** — a document from your library, or in an agent chat
+  a file in the project directory. The reference stays in the sentence you are
+  writing and the contents come with it
+- **`/` for commands** — `/compact`, `/usage`, `/mode plan`, `/model`,
+  `/title`, `/terminal`, `/theme`. `/help` lists them and the keyboard
+  shortcuts beside them. A message that merely starts with a slash is still
+  sent as written
 - **Folders** — arbitrarily nested, delete a folder without losing the chats
   inside it
 - **Web search** — offered to the model as a tool it calls when a question needs
@@ -178,9 +185,10 @@ fingerprint with nothing sent — not your username, not your key — and only
 accepting pins it. If that host later answers with a different key, it is
 refused rather than quietly trusted.
 
-Then start a chat with the **Agent** toggle, pick the connection and a
-directory, and choose a mode. The mode is in the chat header and changes at any
-time:
+Then start a chat with the **Agent** toggle, pick the connection, browse to a
+directory, and choose a mode — all of it under the message box, before you send
+anything. The connection and the directory are fixed once the chat exists; the
+mode changes at any time and stays where you chose it:
 
 | | Reads | Writes files | Runs commands |
 |---|---|---|---|
@@ -198,6 +206,23 @@ with. In **Auto**, nothing stands between that and a command running.
 switches to *Edit*, never *Auto*, because the plan was written under a mode
 where every command still asked.
 
+#### What the model knows about the directory
+
+An agent chat starts by listing the project directory, so a reply does not spend
+its first rounds finding out what is there. It is one read-only command —
+`git ls-files` in a repository, so `.gitignore` is honoured for free, otherwise
+`find` with the usual noise pruned — and it is cached and shared by every chat
+pointed at the same place.
+
+What reaches the model is budgeted rather than dumped: a directory that will not
+fit is shown as `node_modules/ (4,102 files)` and the model is told to open it
+itself if it needs to. **Admin → Agents** sets the budget, and `0` keeps the
+listing for the `@` picker while putting none of it in the prompt.
+
+Listing a directory and browsing one are things *you* asked for, not things a
+model chose, so neither goes through the modes above. Worth knowing if you read
+**Manual** as "nothing happens without me": it means nothing the *model* does.
+
 #### The terminal
 
 An agent chat has a **Terminal** button in its header, which opens a real shell
@@ -207,9 +232,23 @@ the *Open a terminal* permission, which is off by default.
 The modes above do not apply to it. They exist because a model reads pages,
 files and command output it did not write; you hold the credential and could
 open the same shell with an ssh client, so nothing you type is queued for your
-own approval. The model cannot see the panel either — the button in its header
-puts the selection, or the last of the output, into the message box, where you
-read it before it goes anywhere.
+own approval. The model cannot see the panel either — three buttons in its
+header decide what it sees: **Copy** takes the last command and its output to
+the clipboard, **Send** puts the same into the message box, and **Auto**
+collects every command you run into your next message. Nothing is ever sent on
+its own; the box is where you read it first.
+
+Knowing what "the last command" means takes a little help from the shell.
+LLeMbas gives bash and zsh the same invisible markers VS Code and WezTerm use,
+written into a temporary file the shell deletes itself, so it can tell one
+command's output from the next and record the exit status and the directory.
+Your own dotfiles are loaded first and nothing of yours is skipped. Any other
+shell starts exactly as it would have; the two buttons then copy the last of the
+screen as it appeared, say so, and Auto is switched off rather than guessing.
+
+Drag the panel's left edge to make it wider — a terminal narrower than eighty
+columns re-wraps everything a program prints — and the width follows you to
+another browser.
 
 The shell is not tied to the panel. Close it and a build carries on; come back,
 or reload, and you reattach with the scrollback. Two tabs share one shell, and