Sessions in Dyad

*Wayne, 2026-10-28 (in Workbench): "I find myself using a combination of Dyad and Workbench in many of my recent flows. I like the robustness of Workbench for managing multiple coding sessions, but I like the simple Things-like interface of Dyad. I need a tool that will work directly on the Mac or connect remotely to a Mac using either Claude / OpenAI / Hermes / OpenClaw / OpenLLM / Ollama etc. with a connector similar to what we built in the web version of Workbench or in Dyad."*

What this is, and what it is not

It is not a new tool. The decision "One core, many surfaces" (2026-10-23, ~/vault_fbs/3-resources/decisions/M-121.md) already says Workbench is the shell (sessions, files, previews) and Dyad is the workspace, both clients of one core, with nothing replacing a working tool until the replacement has run beside it. A fourth app would be the mistake that decision was made to stop. What Wayne is describing is the shell seen from Dyad's side: the list of live coding sessions as Dyad Items, drawn in Dyad's Things rhythm, reached through Dyad's connector from any Mac, each session on any harness.

What exists today, and the gap.

| Piece | Where it stands today | The gap | |---|---|---| | Many live sessions that outlive the app, with truthful state | Workbench on Herdr (decision M-079): working / blocked / idle / done, resume after reboot, one attach per card | Claude Code only. Workbench's design says "not a Claude client; each session is the CLI in a pty" (~/product-workbench/docs/DESIGN.md line 19). No Codex, goose or other harness as a session kind. | | Reaching a Mac remotely | Workbench's web face at wb.freebeer.ai behind Access (M-075): one Mac, the M1, by hostname | One Mac, one gateway, Cloudflare in the path. Not a connector you install on a second Mac. | | A connector any machine can install | Dyad's daemon (M-103): brew install … dyad, outbound-only pairing, six adapter kinds — shell, Claude Code, Codex, goose, Ollama, any OpenAI-compatible endpoint (~/product-dyad/packages/daemon/src/adapters/) | Adapters run an agent headless (run(bundle, ctx)) for a mention or a task. There is no interactive session: nothing lists the Herdr agents on that Mac, starts one, or streams its terminal to the hub. | | The Things-like face | Dyad web and the SwiftUI app, one target for iOS, iPadOS and macOS (apps/apple/project.yml) | No sessions list, no terminal view. |

So the build is one capability on the daemon and one Item kind in the hub, not a product.

Done, in Wayne's words, made checkable

"Open Dyad on the Mac, or on the iPad against a paired Mac, and see every coding session on that Mac in a Things-like list — start one on the harness I pick, see when it is waiting on me, open it and type into it, and it keeps running when I close the app."

1. The daemon gains a `sessions` capability. On a Mac where Herdr's named workbench session exists, the daemon lists its agents (agent.list on the socket), starts one (workspace create + agent start, the same launch line Workbench uses), attaches a pty stream over the existing outbound connection, and stops one. Capability declared in the manifest; off on machines without Herdr. Check: scripts/adapter-check.mjs extended with a session round trip against the M1 (start, see working, send a line, see blocked, stop). 2. Harness kinds, not model names. A session's kind is a harness that owns a pty: claude (Max login, decision M-010: never a raw API key), codex, goose (against Ollama, LM Studio or any OpenAI-compatible endpoint, which is where "Ollama / OpenLLM / OpenAI" land: goose or Dyad's own adapter is the harness in front of them). The launch line per kind lives in one table in the daemon, the same table Workbench's box reads. Check: one session of each reachable kind started from Dyad shows a truthful state within 5 s of changing. 3. Sessions are Items. Each session is an Item of kind session in Dyad's store (Space = the paired Mac's workspace, Actor = the agent), written by the daemon through Proposal like every other agent write, so it appears in Dyad's web client and the SwiftUI app without a second data path. Check: select count(*) from items where kind='session' matches herdr agent list on the M1 within one tick. 4. The Things-like list, then the terminal. Dyad web and the Apple app draw sessions as a list: one line per session, title · harness · state, grouped by Mac, the Things rhythm from ~/product-dyad/docs/DESIGN.md. Tapping one opens the attached terminal (xterm in the web client, a terminal view in SwiftUI on macOS; on iPhone read-only transcript plus a reply box is enough for this cycle). Check: a screenshot each of the list and an open session on Mac, iPad and web, committed under docs/reports/. 5. Workbench keeps working, unchanged, beside it (the parallel-run rule). Workbench's sessions and Dyad's list are the same Herdr agents; starting one in either shows in both. Nothing in ~/product-workbench is removed in this cycle. Check: make core-test && make build-mac still pass; a session started in Workbench shows in Dyad and vice versa. 6. Which part of life gates the backend. A session in an omnissa or life workspace may only start on a kind that stays on the machine (goose against a local endpoint, or Claude Code, which runs on Wayne's own login) — the stopgap-cloud rule from decision M-007 enforced at the start of a session, not in a document. Check: starting a cloud OpenAI-compatible session in an omnissa workspace is refused with the reason.

Tenant, due, deliverable, cap

• Part of life: fbs. Contexts: product-dyad (daemon, hub, Apple app) and product-workbench (the shared launch table only).
• Due: today, 2026-10-28, per Wayne's standing rule; capacity handled by pausing, not dating ahead.
• Deliverable: code in both repos; this note updated with what shipped; a cutover note per surface under

~/mothership/handoff/cutovers/ when Wayne chooses to use Dyad's list by default.

• Slot: none. This is core work under One core, many surfaces, which holds no venture slot (PORTFOLIO.md, the cap of five).
• Shape: one goal with six chained tasks (daemon sessions capability → harness table → Item kind + Proposal write →

web list + terminal → Apple list + terminal → parallel-run check and report), judge then director check, as in cycles one and two.

Decided already, so not reopened

• Workbench stays macOS-native Swift and is the shell; its web face stays (M-073, M-075).
• Herdr owns the ptys (M-079). The daemon talks to Herdr; it does not grow its own pty server.
• Claude only through Claude Code on the Max login, never an API key (M-010). The subscription path in the connector is

built but not advertised until its terms are cleared (need a-2026-10-17-0001).

• goose is the local runner; Hermes was retired 2026-09-01 after the bake-off (M-015b).

What only Wayne can answer

1. Hermes, OpenClaw, OpenLLM. The vault has Hermes only as the retired gateway (4-archives/projects/Hermes - lab-local.md) and nothing on OpenClaw or OpenLLM. Which of these are harnesses you sit inside (a session kind) and which are model endpoints (an OpenAI-compatible URL goose or the adapter points at)? Endpoints need no work beyond the URL; a harness needs a launch line and Herdr's state detection to be checked against it. 2. The face on the Mac, long term. This cycle puts the list in Dyad and leaves Workbench whole. The next question is whether Workbench's panes fold into Dyad's Mac app later, or Dyad opens sessions in Workbench. My recommendation: fold later, decide after this cycle has run beside Workbench for a week. 3. iPhone this cycle: read-only transcript plus a reply box, or skip the phone until the Mac and iPad are right?

Wayne's layouts, 2026-10-28, and what they change

*"The Mac version of this becomes the centre and right panels of Workbench with Dyad bolted onto the left side in place of the folder tree: a Dyad/Things-type view for managing projects, tasks and habits. The user could choose a project context on the left pane, which would change the context of the bottom centre chatbot. On the iPad, the centre preview pane moves to the top right, with active chat sessions filling the bottom right. On mobile, the view is similar to Dyad today."*

• Host per device. Mac: Workbench hosts (the ptys, previews and web tabs are already there); Dyad's list is the embedded

pane. iPad and iPhone: Dyad hosts; every session is remote through the daemon, so done line 1 is the critical path.

• Sessions belong to projects. Selecting a project sets the box's scope (working folder, part of life, Dyad project id);

a session started there is linked to the project Item; the list groups by project; the tenant gate (done line 6) attaches to the project.

• The file tree is demoted, not removed. A collapsible Files section under the selected project; the swap sits behind

a switch with the old pane the default (parallel-run rule).

• Habits = a repeating to-do with a streak and a quiet check row. One migration, one row style.
• Three layouts are three device classes of one view spec (M-121's grammar): panes written once, laid out per class;

the Dyad web client gets the desktop layout at desktop width, so Workbench's web face only has to serve the M1.

The chain (one goal, eight tasks; Workbench depends on a Dyad package, never the reverse)

1. Daemon sessions capability: list · start · attach pty stream · stop, over the outbound connection, against Herdr. 2. One harness table (claude · codex · goose over a local or OpenAI-compatible endpoint), read by Workbench's box and the daemon. 3. Sessions as Items through Proposal; Space = the project. 4. DyadKit: the left pane as a SwiftUI package (projects · tasks · habits), publishing the selected project's context. 5. Workbench Mac: left-pane swap behind a switch; Files section under the project; box scope follows the selection. 6. Dyad iPad: list left · preview top-right · sessions bottom-right, over the remote backend; same layout in the web client. 7. Dyad iPhone: a sessions section, transcript plus reply box. 8. Parallel-run check · report · cutover note.

Assumed unless Wayne says otherwise: the box with a project selected launches a session in that project; chat with Hugh stays Dyad's channel work (cycle three of One core). Question 2 above is answered by this section; questions 1 and 3 stand.