Files

T

jpmschweitzerandClaude Opus 4.8 5dfea07bff docs(briefings): log worktree-sandbox dead-end + image.show win (clide)

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>

2026-06-07 12:57:10 +02:00

7.3 KiB

Raw Blame History

title, description, type, status, created, tags

title

description

type

status

created

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)

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.
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.
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).

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.
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.
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.
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).

Create agent/teammate worktrees inside the writable root (e.g. main/.worktrees/<branch>), or
Extend the sandbox's writable root to cover the repo's sibling worktrees, or
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.

7.3 KiB Raw Blame History