--- title: "clide friction log — for the clide team" description: "Observed friction + improvement notes while driving clide as the Settled Reach IDE, esp. the untested team-mode UI. Hand-off material for the clide team." type: briefing status: active created: 2026-06-07 tags: [clide, ide, team-mode, friction, feedback] --- # clide friction log — for the clide team Running notes on where clide helps and where it creaks, captured live while using it as the Settled Reach IDE. Intended as hand-off material for the clide team (the `projects/clide` repo). Each item: **what**, **impact**, **suggested fix**. ## Already observed (pre team-mode) 1. **Diff view is working-tree only — no committed/branch-vs-main diff.** `clide ui open diff ` and `clide git diff` show only uncommitted changes; there's no verb to view a *committed* branch-vs-`main` diff. So for reviewing an already-committed PR, the diff view is empty. *Impact:* can't "look at a PR diff with the user" in clide — had to fall back to /pr-review. *Fix:* a `clide ui open diff --base main` (or `clide git diff --range main...HEAD`) that renders a committed range diff in the diff tab. This is the single biggest gap found so far. 2. **`capabilities` is excellent.** Live dispatcher registry, never drifts — exactly the right discovery primitive. Keep it; consider linking it from `clide --help`'s top usage line. 3. **`ui toast` + `ui open` + `status` parity works well.** `shown:true`/`opened:true` returns are clear; `status` gives a clean one-shot orientation (panes/git/editor/readers). ## Team-mode UI (under test — 2026-06-07) Context: lead is inside tmux (`TMUX` set), `teammateMode: auto`, so teammates spawn as tmux panes clide is expected to render. This is the untested surface. Observations appended below as the Q-101 workshop runs. ### FINDING T1 — clide UI does not reflect team mode (HEADLINE) — 2026-06-07 **What.** Ran a real team (`TeamCreate` + an Agent teammate `Tyre`, `teammateMode: auto`, lead in tmux) to run a design workshop. The **work layer functioned perfectly** — Tyre spawned, read the brief, and wrote a 16 KB `tyre-round1.md`; task-list + file + message coordination all worked. But **clide's UI never reflected any of it** (user-reported: "both the team-mode side-panel pane and the clide renders are not responding to team mode"). **Diagnostics.** - clide has a `claude.team-chat` view (`visible:true`) but it sits `active:false` and shows no teammate activity — the scaffold exists, the wiring doesn't. - Teammates spawn as **separate tmux sessions** (observed: 27 sessions vs the lead's session `25`). clide does not adopt/render those sessions — `clide pane list`/`status` enumerate only clide's own Flutter views, never the teammate panes. - `clide capabilities` exposes **no `team`/`agent`/`chat` subsystem** — there's no CLI verb to observe team state, list members, or read the team chat. (Confirmed against the live registry.) **Impact.** Team mode is effectively invisible inside clide: the user can't watch teammates, read the team chat, or see per-teammate progress. The lead can only observe via Claude-side tools (`TaskList`, `SendMessage`, reading output files) — none of which surface in clide. For a multi-agent workshop this removes the entire point of the IDE's team UI. **Suggested fixes (for the clide team).** 1. **Wire `claude.team-chat` to the live message bus** — subscribe to the same team mailbox the lead/teammates use so DMs + broadcasts render in the Team Chat view as they happen. 2. **Adopt teammate tmux sessions into clide's pane model** — when a teammate spawns (separate tmux session), surface it as a clide pane/tab (one per teammate) so the user can watch each one; enumerate them in `clide pane list` with `source: team`. 3. **Add a `clide team` subsystem** — `team list` (members + status), `team chat [--tail]`, `team focus ` (open that teammate's pane). Parity: the lead drives team mode via Claude tools; clide should *observe* it, per the D-6 contract. 4. Until then, a smaller stopgap: have the Team Chat view at least show "team active: N members" + the task-list state, so the user knows team mode is live even without full rendering. **Refinement — the teammate ran `in-process`, not a tmux pane.** Tyre's shutdown ack reported `backendType: in-process`, `paneId: in-process`. So under `teammateMode: auto` inside clide the teammate took the **in-process fallback** rather than spawning a tmux split — which means there was *no pane for clide to adopt or render in the first place*. (The 27-vs-25 tmux session delta seen earlier is unrelated background sessions, not this teammate.) This sharpens the fix: - The likely root cause is the **auto → in-process fallback firing inside clide** (clide's PTY/tmux env isn't detected as splittable), so team mode degrades to invisible in-process agents. - Fix options for the clide team: (a) make clide a first-class `teammateMode: tmux` host so teammates spawn as adoptable panes; **and/or** (b) render *in-process* teammates too — subscribe the `claude.team-chat` view to the in-process team mailbox so even fallback teammates are visible. (b) is the more robust fix since in-process will always be a possible backend. **Workaround taken this session.** Kept Tyre's delivered round-1; ran the rest of the Q-101 workshop as **background Agent subagents** (the Si/reviewer pattern), which DO surface in clide's normal Claude activity flow — i.e. avoid `teammateMode` teammates until the team-chat view is wired to the mailbox. ### FINDING T2 — background agent + out-of-root worktree is a sandbox dead-end — 2026-06-07 **What.** Spawned a background Agent (not a `teammateMode` teammate) to implement a server ticket in an isolated git worktree at `/var/mnt/data/projects/settled-reach/.worktrees/` — a *sibling* of the session root `/var/mnt/data/projects/settled-reach/main`. The agent could Read/Grep/cargo fine and produced a complete design, but **every `Edit`/`Write` was denied**: sandboxed file writes are confined to the session's project root, so the sibling `.worktrees/` path is unwritable — by the agent *and* by the lead. It is not a clide permission toggle; there is nothing to "grant." **Impact.** The whole background-agent-in-worktree isolation pattern is unusable under the current sandbox: the agent burns a full run designing, then blocks at the first write. The user (reasonably) looked for a permission to grant and found none. Fallback was to drop the worktree and implement in the main checkout on the branch. **Suggested fixes (for the clide team).** 1. Create agent/teammate worktrees *inside* the writable root (e.g. `main/.worktrees/`), or 2. Extend the sandbox's writable root to cover the repo's sibling worktrees, or 3. At minimum, fail fast with one clear up-front error ("worktree path is outside the writable root") instead of per-`Edit` denials that read as a grantable permission. ### Positive — `clide image show` works well — 2026-06-07 `clide image show --caption "..."` rendered and displayed a generated diagram first try, with a clean `{shown:true}` return. A solid parity data point alongside the team-mode gaps — the observe/drive surface (D-6) is sound where it's wired; the gap is specifically team-mode rendering, not the CLI model.