jpmschweitzerandClaude Opus 4.8
5dfea07bff
T2: background agent / lead writes are confined to the session root, so an out-of-root sibling worktree (.worktrees/<branch>) is unwritable — the agent could design but not write, and there's no permission to grant. Fix options for clide noted. Plus a positive: clide image show works first-try. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
112 lines
7.3 KiB
Markdown
112 lines
7.3 KiB
Markdown
---
|
|
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 <path>`
|
|
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 <path> --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 <name>` (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/<branch>` — 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/<branch>`), 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 <path> --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.
|