multi-agent-mux/.agents/reports/cline_deprecation_opinion.md

🏛️ Consensus Opinion — Should cline Agent Support Be Removed?

• Planner (synthesizer): planner-reviewer-claude-01
• Job: a33a133e
• Participants: planner-reviewer-claude-01 (self), reviewer-creator-grok-01 (job e0916903), reviewer-hermes-01 (job 57f33eff)
• Method: This is a genuine 3-way consensus, not a solo synthesis. The other two opinions were collected by actually delegating a job to each live session via multi-agent-mux-delegate-job submit (real MQTT-tracked jobs, real independent analysis in their own panes — verified by reading their live pane output while they worked, not just their final reports) and reading their full written reports at .mam/jobs/e0916903/grok-reports/report-final.md and .mam/jobs/57f33eff/hermes-reports/report-final.md. No skill/framework code was modified by any participant.
• Status: Rev.3 — refined per reviewer-creator-grok-01 (job 0a056794) and reviewer-hermes-01 (job bc68ed65) reviews. Still no unanimous verdict; see §4 for the honest split and §6 for the recommended path forward.

---

0. Changelog

Rev.3 (response to reviewer-creator-grok-01 & reviewer-hermes-01 reviews)

• F1 (Flag inventory accuracy): Corrected §3.2 and §6.2 to cite -k, --key <api-key> (which exists on cline --help for startup key injection) while bounding its scope: it does not refresh credentials mid-task nor suppress interactive modal fallback on provider failure, and confirmed no --headless/--non-interactive flag exists.
• F2 (drift-C modernization status): Corrected §2 point 3 and §6.1 to accurately note that sibling_claimed exclusion and epoch filtering currently exist only in agy (~line 692) and hermes (~line 742) blocks; claude (~line 637) and cline (~line 785) both lack this pattern.
• F3 (Consensus attribution): Clarified §2 point 3 and §6.1 regarding drift-C modernization: Hermes requires it as a condition of RETAIN and Planner treats it as urgent, while Grok views the block as maintenance debt to be deleted under REMOVE.

Rev.2 (response to creator-agy-01 challenge)

• §3.1 rewritten: risk escalated from "narrow spawn-time race" to "unmonitored mid-task modal-fallback window," with the verification trail (what's confirmed vs. inferred) laid out explicitly.
• §3.2 narrowed to reaffirm only the tool-call-approval finding that still stands (--auto-approve default true).
• New §3.4: precision-scoped the session-hijacking concern (cline's discover() does filter by workspace cwd, so exposure is concurrent-same-workspace activity, not all 40 sessions indiscriminately).
• §4 & §6 revised: RETAIN vote conditioned on mandatory safety gates; empirical testing prioritized.

---

1. Individual Verdicts

Reviewer	Verdict	One-line reasoning
reviewer-creator-grok-01	REMOVE	cline fails two hard contracts every other shipped adapter now meets (unattended execution, assignable session identity); its reviewer niche is already filled by hermes in this live workspace.
reviewer-hermes-01	RETAIN (conditional)	cline's hardest TUI problems were already fixed and generalized into shared framework infra; remaining cost is tuple-membership-scale; 40 active standalone ~/.cline/data/sessions folders show sustained real usage outside MAM.
planner-reviewer-claude-01 (self)	RETAIN (revised, conditional)	Started leaning REMOVE on two concrete compatibility taxes I found myself, but revised after independently verifying hermes's session-count claim — see §3.

2 of 3 lean RETAIN (both conditional on the same follow-up fix), 1 of 3 leans REMOVE with a well-argued, non-dismissible technical case. This is presented honestly below rather than forced into false unanimity.

---

2. Where All Three Reports Fully Agree (cross-verified independently, not just asserted)

These points appeared in at least two of the three independent analyses and I re-verified each against the live repo/environment myself before including them here:

1. The Node.js/Ink TUI rendering quirks are real, but already paid for and generalized — not live, ongoing debt. Specifically:
   • lib.sh:2108–2113's whitespace-normalized paste-marker matching exists because of a documented cline-specific quirk (soft-wrap continuation lines get a hanging indent), but the fix collapses all whitespace and now protects every agent's paste verification, not just cline's.
   • The "skip strict paste check" exemption list (lib.sh:2126) includes cline alongside claude/agy/grok — it originated from cline but is now a shared, multi-agent carve-out (only hermes is not in this list, per grok's report, which I independently confirmed by reading the line).
2. modal_tokens is not cline-exclusive baggage. claude.py also declares a modal_tokens property (for its own, unrelated "fullscreen upsell modal," per the very recent commit 17edf90 visible in this repo's git log). I confirmed this via grep -n "modal_tokens" .agents/skills/lib_py/agents/adapters/*.py — only claude.py and cline.py override it. The generic modal-handling mechanism (handle_startup_dialogs, the 2-tier readiness model from commit 17edf90) is shared framework infrastructure that cline motivated but does not exclusively own.
3. reconcile.sh drift-C blocks for cline and claude remain un-modernized technical debt. Only agy (~line 692) and hermes (~line 742) drift blocks currently build a sibling_claimed/_sibling_claimed_uuids exclusion and row-level epoch filter; cline (~line 785) and claude (~line 637) blocks still verify candidates against the raw row s without sibling-claim exclusion. Modernizing cline's block is required by Hermes as a condition of RETAIN and prioritized by Planner, while Grok notes the block would simply be deleted if REMOVE is chosen.
4. No cline session is currently running in .mam/agent-sessions.yaml (verified: the live roster is planner-reviewer-claude-01, reviewer-creator-grok-01, creator-agy-01, reviewer-hermes-01).
5. cline cannot accept an externally pre-assigned session UUID at spawn (its IDs are self-assigned, timestamp-based — 1785635248957_fajon-style, not UUIDs) — unlike claude/grok's --session-id pre-assignment pattern from MULTI_AGENT_RULES.md §2. This is a genuine, permanent architectural mismatch with MAM's P0 identity protocol, not a bug to fix.
6. Removal, if chosen, is mechanical and low-risk: ~19–20 live files (adapter, registry, 4 lib_py modules, lib.sh, 8–9 skill scripts, 5–7 SKILL.md docs, ~6 test files), git history preserves reversion, and the grok integration already proved the reverse operation (adding an agent) costs ~0.5–1.5 days — so re-adding cline later, if ever needed, is a known, bounded cost. Historical .agents/reports/**/*cline* files must not be touched either way — they're durable audit-trail history per MULTI_AGENT_RULES.md §4, not live framework surface.

---

3. Where the Reports Diverge — the Actual Crux, and a Factual Correction

3.1 The crux: does the setup-modal / no-external-UUID gap disqualify cline from unattended roles, or is it already contained? (Rev.2: revised, risk escalated)

Rev.1's position (now superseded): I originally argued the pre-spawn cline history --json gate in create_session.sh contains the setup-modal risk to a narrow spawn-time race — "an already-configured cline whose config gets corrupted between the gate-check and spawn."

Why that was wrong, per creator-agy-01's challenge (accepted): cline history --json's own help text describes it as "List session history or manage saved sessions" — I ran cline history --help myself and confirmed there is nothing in it that checks API-key validity, OAuth token expiry, remaining quota, or endpoint reachability. It only proves local session storage is readable. This is structurally different from claude auth status, hermes status, or agy's OAuth-credential-file check, all of which validate something closer to "can this agent actually talk to its provider right now," not just "does a local directory exist." So the gate does not protect against the scenario that actually matters for a long-running unattended task: a credential going stale or a provider erroring out mid-task, well after spawn-time.

The escalated risk model (accepted as the working assumption): during autonomous multi-step work, a 401 (expired token), 429 (quota exhaustion), or provider-endpoint change could plausibly cause cline's Ink-based TUI to fall back into the same interactive Select API Provider | Enter API Key modal its modal_tokens property already exists to detect — except now mid-task, not at startup. I checked exactly where MAM watches for this modal (lib.sh's _pane_dialog_open/modal_pat mechanism) and confirmed it is only checked at two points: inside wait_for_tui_ready's spawn-time loop, and inside send_keys_safe's pre-injection dialog-wait loop (i.e., only when MAM is about to send the next prompt). There is no continuous/periodic check of a working agent's pane for a spontaneously-appearing modal during an autonomous stretch where MAM isn't actively injecting anything. If a modal appears in that window, nothing in the current code path notices it specifically — the process just sits alive-but-idle until the generic idle_timeout_sec/watchdog eventually times it out, which (unlike a clean non-zero-exit failure from the other four agents) produces an unlabeled stall rather than a diagnosable error event MAM could act on or retry immediately.

Honesty caveat: I want to be precise about what's verified vs. inferred, matching the standard I've held to throughout this consensus process. What I verified: the gate's actual scope (local-only), and the modal-check mechanism's actual scope (spawn + injection-time only, not continuous). What remains inferred, not observed: that cline's TUI genuinely falls back to this specific modal on a 401/429 specifically (as opposed to, say, printing an error to its own log and hanging some other way, or exiting cleanly like the other agents). Neither creator-agy-01 nor I have triggered a live auth failure against a running cline session to watch what actually happens. Given the architectural gap (no continuous modal monitoring) is real regardless of cline's exact failure behavior, I'm adopting the escalated risk model as the planning assumption — the precautionary principle applies here, since the cost of being wrong in the "assume it's risky" direction is just some unnecessary caution, while the cost of being wrong in the other direction is a genuinely undiagnosable silent stall in production. This is Rev.2's position; §6 still calls for closing this empirically before treating either side's confidence as final.

3.2 On tool-call approval and API key flags (Rev.3: corrected flag inventory)

I checked the actual installed cline CLI (v3.0.60) myself: cline --help shows --auto-approve <boolean> with default: true, and -k, --key <api-key> for API key override at run-time.

• On the tool-call auto-approval axis (bash/file-write "Allow this? [y/N]" prompts): cline is non-blocking by default.
• On the credential & unattended execution axis: -k, --key allows supplying an API key at startup, but it cannot refresh an expired credential mid-task nor suppress the interactive TUI fallback when a provider rejects the key during an autonomous stretch. Confirmed: no --headless or --non-interactive flag exists in cline --help that would force non-interactive exit on provider error.

3.3 The 40-session fact that shifted my own vote

reviewer-hermes-01's report cited 40 session folders under ~/.cline/data/sessions, dated back to June 2026, as evidence of sustained standalone use outside MAM. I independently verified this (ls ~/.cline/data/sessions | wc -l → 40; oldest folder 1782614591159_mrkxj dated Jun 30). I had not checked this myself before drafting my own initial opinion, which was leaning REMOVE on the strength of the TUI-quirk findings alone. This fact — that the user is actively using cline as a real tool, independent of whether MAM currently has a live cline session — is the deciding factor in my revised RETAIN position: MAM's purpose is to orchestrate the user's actual agents, and cline is plausibly a tool the user will ask MAM to delegate to again, at a marginal ongoing cost (one adapter + tuple memberships) that neither report characterizes as disproportionate once the TUI-quirk debt is netted out as already-paid/generalized (§2.1).

3.4 A tension in my own Rev.1 reasoning, surfaced by the challenge (new in Rev.2)

creator-agy-01 correctly points out that the same 40-session fact I used in §3.3 to support RETAIN also worsens a different risk I'd only mentioned in passing (§2 point 5): cline.py::discover() resolves an unknown session by sorting ~/.cline/data/sessions/* by mtime descending and taking the newest valid candidate. The heavier the user's independent standalone cline usage, the more often a MAM-orchestrated session's identity-discovery could, in principle, race against a session the user started manually around the same time.

Precision I want to add rather than just accept the claim at face value: I re-read cline.py::verify_artifact() — it does check found_cwd/workspace_root against the target workspace via workspace_key() before a candidate is accepted, so discover() is not indiscriminately grabbing from all 40 sessions — only ones whose recorded cwd matches the workspace MAM is operating in. This narrows the exposure to concurrent cline activity in the same repository/workspace, not any of the user's 40 sessions system-wide. It does not eliminate the risk: if the user happens to run cline manually in this repo while a MAM-orchestrated cline session is also active here, the two share no sibling-exclusion or epoch discipline today (§2 point 3), so misattribution is real and currently unmitigated for that overlap case. Net: creator-agy-01's point stands, scoped more precisely than the raw "40 sessions" framing implies.

---

4. The Honest Split

This is not a case where two "obviously correct" opinions outvote one weaker one. Grok's REMOVE case rests on a real, permanent architectural fact (no external UUID assignment) plus a real unattended-execution gap that Rev.2/Rev.3 characterizes sharply (§3.1: not just a narrow spawn-time race, but an unmonitored mid-task modal-fallback window) — and correctly notes that cline currently contributes zero live MAM sessions while carrying the most special-cased adapter contract of the five. Hermes's and my RETAIN case rests on the TUI-quirk debt being mostly sunk/shared already, the removal buying comparatively little given that, and real evidence of continued user investment in the tool. Rev.3 does not change my RETAIN vote, but it maintains its strict terms: RETAIN is only defensible if paired with the safety-gate restriction in §6.2. Both REMOVE and conditional-RETAIN remain defensible; this consensus report does not manufacture false agreement where genuine disagreement exists.

---

5. Removal Blast Radius (preserved from grok's report, for use if REMOVE is chosen regardless of this consensus)

If the General Manager decides to proceed with removal despite the 2/3 RETAIN lean, reviewer-creator-grok-01's report already did the enumeration work — reproduced here so it isn't lost:

• Drop ClineAgentAdapter, its registry.py entry, and every case/tuple-membership site across create_session.sh, resume_session.sh, resolve_session_id.sh, stop_session.sh, status.sh, reconcile.sh, update_yaml_resumed.sh, orc_onboard.sh, run_loop.sh, lib.sh (kind mapping, name/cmd fallback, spawn-token strip list, send_keys_safe case, paste-skip list), atomic_yaml.py, verify_session.py, workspace_uuid.py.
• Remove the cline-only ^[0-9]{10,}_[0-9A-Za-z]+$ ID-format union in orc_onboard.sh and its node-as-argv0 ancestor-walk accommodation.
• Do not delete _pane_quiescent, the whitespace-normalized paste matching, or the paste-skip list itself (only cline's membership in that list) — these serve claude/agy/grok too.
• Retarget, don't drop, tests that use cline as a TUI fixture (test_c1_tui_readiness.py's wait_for_tui_ready dummy-sess cline usage, test_orc_onboard.py::test_o31_cline_node_launcher_id_format) — repoint them at grok/hermes/claude rather than deleting coverage.
• Update the 5–7 SKILL.md docs' supported-agent lists.
• Single coordinated change, not a drive-by delete of cline.py alone — a partial removal will immediately fail test_tier1_unit.py's 5-tuple whitelist assertions.

---

6. Recommended Path Forward (regardless of REMOVE vs. RETAIN)

1. Modernize drift-C blocks in reconcile.sh (urgent for RETAIN): Sibling-exclusion and epoch discipline have shipped for agy and hermes, but remain missing in both cline (~line 785) and claude (~line 637). If RETAIN is chosen, modernizing cline's block (alongside claude's) is a required condition (supported by Hermes and prioritized by Planner; Grok notes this block is deleted if REMOVE is chosen). Rev.2's §3.4 sharpens why: the more heavily the user runs cline standalone, the more this unmitigated gap matters.
2. If RETAIN — mandatory safety gate: cline must be explicitly excluded from long-running autonomous Creator/Worker roles until upstream ships a documented flag that suppresses the credential-failure interactive fallback (no --headless/--non-interactive flag exists today; -k, --key only provides startup key override). Scope cline to short-lived, actively-supervised, or single-shot interactive use only. This should be written into MULTI_AGENT_RULES.md as an explicit per-agent capability restriction, not left as an informal understanding. Revisit after an observation window (e.g., one release cycle) using live MAM session-registry history as the evidence bar, not anticipation.
3. If REMOVE: follow §5's blast-radius list exactly, as a single coordinated PR, with the preservation constraints called out there.
4. Close the open empirical question from §3.1: an actual live cline -i spawn test that deliberately induces a credential failure mid-task (e.g., revoke/expire the API key while a multi-step task is running, mirroring the rigor applied to hermes's live spawn test in job 28f9b565) would resolve whether the modal-fallback risk is observed fact or remains a plausible-but-untriggered inference. Neither side of this consensus has that data point yet — Rev.2/Rev.3 upgrades this from "nice to have" to "should happen before cline is trusted with any new unattended work."

This report deliberately stops short of a unilateral Planner override of a 2-1 split reviewer vote — per MULTI_AGENT_RULES.md §3, that decision belongs to the General Manager, informed by this synthesis, not to the Planner alone.