Logbook
Logbook
The Logbook is the archive on one screen: every session every harness has produced, whoever started them and whichever machine wrote them, newest first.
It is the answer to "when did I ask about this", which is a question nobody can answer from seven CLIs with seven histories.
Three lists, one bar
The toggle in the page bar swaps which list the table is showing. All three share the same density, the same search box and the same reader.
Drawing the diagram…
Sessions
Where the rows come from
Nothing is scraped from a screen. Each harness keeps its own history in its own format, and mechabedo reads that format.
Drawing the diagram…
Import is idempotent. A transcript's id is <harness>:<native-session-id> and a sync compares fingerprints before it parses anything, so importing twice adds nothing the second time. That is why the button says Import rather than Refresh; the second button next to it forces a re-read of sessions whose fingerprint has not moved, which is what you want after a change to how something is parsed.
On a machine that has imported nothing, that button is the page.
Table and focused
With no session open, the list is the table: the column grid below, sortable, with the totals row.
Open a session and the list beside the reader becomes focused: one row per session, the title, then the project and the time on the line below. It is newest first and grouped by day, each day header carrying the date, and the working directory is in the project's hover. Close the reader and the table comes back.
The columns
Every column except the session title can be hidden from the picker in the page bar, and the same menu holds the row density and the day grouping. The columns that hold numbers drop out when the list itself is narrow. What you choose is remembered.
| Column | What it holds |
|---|---|
| Title | The harness's own, or the name you gave it |
| Harness | Which agent wrote it |
| Machine | Where it was written. Appears once the archive holds sessions from more than one machine |
| Project | The directory it ran in |
| Filed as | The category you filed it under, in the reader. Off until you turn it on |
| Turns | Prompts you typed |
| Agent | Turns the agent itself ended. Appears once the page holds a harness that records one; a dash means that harness records none |
| Tools | Tool calls it made, with what it reached for in the hover |
| Effort | The reasoning effort it was set to, with its reasoning-token count |
| Cache | Cache reads as a share of all prompt-side tokens |
| Working | How long the agent spent working |
| Idle | How long the session waited: for the next prompt, from you or an agent driving it, or through any silence past five minutes |
| Rated | What you thought of it, as a signed total. Off until you turn it on |
A tilde means estimated
A token figure with a leading tilde was not reported by the agent; mechabedo counted it locally. The hover says so. Nothing estimated ever reaches the meter.
Four columns are also buttons. Pressing the harness mark, the machine, the project or a category narrows the archive to that value and puts it in the bar as a chip. Pressing it again clears it. The filter goes to the server, so it narrows the archive rather than the page that happens to be loaded.
Searching what was said
The box searches inside the transcripts, not only across their titles.
Scopes appear with the first character you type: Names and Prompts on, Thinking a press away. A session matched on what was said says so on a line of its own under its row, indented, with the matched words marked and a quote mark for a prompt or a thought bubble for reasoning. Pressing that line opens the session at that message with the term already in the reader's find.
While the index is still filling, the footer says how much of the archive it covers - because a thin answer during the first backfill looks exactly like an empty archive.
Totals
In the table layout, the first row, marked with a sigma, sums what the table lists: messages, turns, tool calls, tokens, reasoning, cost, ratings, and how many projects, models and machines those sessions span. A filter or a search re-sums it. Pick two or more rows and it sums only those. Its label says which it is: in total, loaded, matching or picked.
Days as folds
Grouping by day gives the archive the shape the session rail gives a project: one collapsible header per day, carrying that day's session count and billable tokens.
The focused list beside the reader always groups. In the table it applies only while the table sorts on age. A day header over rows ordered by cost describes nothing, so any other sort renders flat and the menu says so.
Reading one
Selecting a row splits the page; the ratio and the axis are yours to drag, and both are remembered.
| Layout | What is up | How you get there |
|---|---|---|
| List | The table alone | No selection, or closing the reader |
| Split | Both, on a dragged ratio, beside or below | Selecting a row |
| Read | The reader alone, chrome folded away | f, the expand button, or a double-click on the grip |
A transcript is drawn the way the workbench draws a live session: the same message blocks, the same reasoning folds, and each run of tool calls folded into one "N tool calls" line, so a session opens folded and reads as its prompts and replies. One vocabulary, not two.
The reader's title bar is the workbench's own, in the same order:
| Control | What it does |
|---|---|
| Pencil, or a double-click on the title | Rename the session |
| Wand | Ask a small model for a title from the first prompt and the last reply |
| Summary | Fold the work between two turns into a short summary a small model writes |
| Replies only | Show only your prompts and the replies. The thinking and tool toggles are off while it is on |
Summary and replies only are one switch for the whole window, shared with the workbench: turn one on here and the workbench reads that way too.
| Key | What it does |
|---|---|
j k | Move the cursor. In Read, each move opens that session |
/ | The search, unfolding the bar first if it is away |
\ | Swap the split axis |
[ ] | Move the ratio |
a | Send the selection to the Refinery |
Escape | Peels one layer: the find, then Read, then the reader, then the selection |
Renaming. A harness derives a title from the first prompt, which is often the wrong name for what the session turned out to be. Enter or leaving the field keeps the new name, Escape cancels, and an empty title gives the harness's own back. The new name is kept in a column no import writes, so the next sync of that harness leaves it alone, and every read prefers it - the list, the reader and the search alike.
What it kept. Under the filing row, the reader lists the memory records this session wrote, retired ones struck through. It is the other direction of the Keep action in the same pane.
Secrets. When a session holds something shaped like a credential, a chip beside its title says how many. It is red when one of them works beyond this machine, such as a provider key, and amber otherwise. Click it for the list: the rule that matched, where it is, and a preview with the value masked. Choose one to jump to that message, with its tool calls unfolded. A session with nothing found shows no chip. The value itself is never shown, so the chip is safe to look at with someone watching.
Exporting
The reader's menu exports the session as one HTML file that opens anywhere, offline, with both palettes inside it. The selection bar's Export does the same for the sessions you picked, including ones a later filter scrolled out of the list, and the page bar's export button for every session the filters match, not just the ones loaded so far. Either way you get one combined file.
A bulk export shows how far it has got and can be cancelled. A session that cannot be read does not stop it: the dialog names it with the reason, the file lists it at the end under Not in this report, and Retry reads only the missing ones again. The file opens on your prompts and the replies, with a Replies only button in its header that shows the tools and reasoning again; switch Replies-only view off in the export dialog to have it open on everything. It is not a summary, because a file cannot call a model, and nothing is left out of the file by it: the dialog's Tools and Reasoning switches decide that.
Before you export, the dialog's Secrets section lists any credentials found in what goes into the file, grouped by rule, including parts the file's own toggles would hide. Switch Mask secrets on to replace each value with [redacted:<rule>] in the file; its footer then says how many were masked. It is off by default, and nothing stops the export either way: the choice is yours.
Memory
The second list is what earlier sessions settled about a directory, as statements rather than as a transcript to search.
A record is a kind, the record itself, the project it holds for, and two ages: when it was kept and when it was last carried into a session. Retired records are struck through rather than hidden, because the change is the point.
| Kind | What it records |
|---|---|
decision | A call that was made |
constraint | A rule the work has to follow |
state | Where the work stands |
preference | How you work |
reference | Something worth reading |
A session opening in that directory is handed the most relevant few. That is the whole mechanism: the next session does not re-derive what the last one worked out.
A record is kept in one of three places:
| Kept for | Read by |
|---|---|
| A project | Sessions in that directory and under it. When the directory is a git repository, also sessions in the same repository on your other machines, whatever its path there |
| A machine | Sessions on that machine only, for a fact about the machine rather than the project |
| Everywhere | Every session, for something true of you wherever you work |
Keep picks one of them, with your machines listed by name, so a session on one machine can write down a fact about another.
When your machines share a logbook through the beam, records kept for a repository, a machine or everywhere travel with it, sealed like the sessions. A record kept for a directory that is not a repository stays on the machine that kept it.
Code
The third list is what mechabedo has indexed of the code in a project, so a session can find a declaration by what it does rather than by a string it contains.
Drawing the diagram…
No source text is stored. A chunk is a location. The snippet is read off disk when a search answers, so the index can never serve a stale line - a file that changed without being re-indexed costs a wrong range, which you see immediately, rather than wrong content, which you would not.
A symbol-shaped query drops the vector list. A query carrying a slash, a dot, camelCase or an underscore is a name you already know, and a vector neighbour of useUnifiedChat is not what you asked for.
Nothing is indexed on its own
Three ways in, all of them yours:
- Turn it on for a project, or type a root into the box at the top of the Code view.
- On the first search, where you allowed auto-index for that root. The tool then answers "indexing, ask again" with progress rather than blocking.
- Never - which answers "this project is not indexed" and names the switch.
Refresh is incremental: a file listing that honours .gitignore, a content hash per file, and only the changed files re-chunked.
Looking inside it
Open a row and there is a second search box under it. That one runs exactly the search an agent runs, against exactly that project, and shows the same ranking the agent is handed.
That is the point of the view as much as the list is: a semantic index nobody can look inside is a black box that degrades silently.
It needs switching on first
Settings, mechabedo coding agent, Code index. That section also chooses what reads your files and where the embeddings come from. Embeddings are optional: with none configured the search still answers by symbol name and by text, and says so.
Read by agents
The archive is offered to running sessions as a read-only tool surface, so an agent can look up what an earlier session decided instead of guessing. A session searching the archive, reading one, and finding the sessions that touched a file are all one tool call each.
That is the reason the archive exists in this shape: it is not a log for you to scroll, it is a corpus your agents can query.
Next
- Transcripts - what is recorded, and from where
- Refinery - what happens to an archived session when you want it documented
- Settings - where the code index is switched on