fix(*): stop the connect button promising what it cannot do

[LivXue]

Summary

The agents page offered a Connect that could not be trusted, in two separate ways, and this
closes both.

A press held for as long as the server's readiness gate takes -- one real prompt through that
agent's own backend, measured at 16s against a live adapter -- and nothing on the row said it
had begun. A reader with nothing to look at pressed again. The second press then killed the
first: the connection pool keys a connection on its launch arguments, cwd among them, and cwd
falls back to the calling task's workspace, so a ping's key never matches a held connection
and acquire retires it. The first press came back "sub-agent did not answer a test message",
naming the agent for a failure raven had caused. Reproduced on a live gateway: press one
failed at 3.0s, exactly the click interval; press two succeeded at 17.1s.

Two changes, either of which alone leaves a hole. The page holds a row while its own write is
in flight, the way the Test button beside it always has -- the writes only, since test_cancel
has to reach the server while its test is still running. And a readiness ping now runs on a
connection pool of its own, closed on the way out, which also stops a ping fired while the
agent is serving a real run from taking that run's connection with it. The same A/B afterwards:
both presses succeeded, 15.0s and 13.2s, with no relaunch between them.

The second way was the button itself. Four of the eight third-party agents this machine can
offer would refuse the press and always would have: three have no binary on PATH, and one
answers the handshake and then declines to open a session without a credential. Each carried a
Connect identical to a working row's. The page now says which it is and offers nothing --
"Not Installed" for a command that does not resolve, "Unauthorized" for an agent that asked to
be signed in. Neither is pressable, because neither remedy is on this page; the way back is the
card's own Test, which re-measures and replaces the recorded verdict, plus a restart, which
re-measures a recorded refusal rather than trusting it. A connected row is untouched, so an
expired credential cannot cost it the Disconnect it still needs.

needs_auth is measured, not inferred, and it takes the refusal's own words. verify_agent
already read a verdict off the handshake's auth methods and the error text, spent it on
choosing a status, and dropped it; the advertisement half is not evidence about any one
refusal, because an agent that works advertises auth methods too -- one measured here names
four -- so needs_auth takes only the credential-shaped refusal while the coarse status keeps
the reading it always had. The snapshot then carries the verdict and nothing downstream
pattern-matches an agent's prose. Two
supporting changes follow: the snapshot backfill now records a credential refusal as well as a
pass, and covers shipped presets nobody has configured, which is exactly the set whose Connect
was about to mislead.

Costs and residue, all deliberate:

• The backfill now handshakes the shipped acp presets that are on this machine, not only the
  configured rows: 9 instead of 4 here. Sequential, backgrounded, no model tokens. A preset
  whose command does not resolve is skipped, so nothing is launched to learn what the free
  probe already answered.
• Recording a non-ready snapshot is narrowed to credential refusals. A timeout or a crashed
  adapter stays unrecorded, because that is a fact about one minute and freezing it would
  label a working agent broken until somebody pressed Test.
• The snapshot store gains at most one row per shipped preset.
• The TUI roster reads the same rows and calls the same subagents.add / subagents.toggle. It
  does not read needs_auth, so its button is unchanged -- not a regression, and not fixed here
  because it would widen the diff into another surface. Named so a reviewer does not have to
  find it.
• Recording a preset's snapshot also means a preset row's stateful and its probe status are
  read from a measurement rather than defaulted. More accurate in both cases, and named here
  because it is a second consequence of one line.
• A Test records a snapshot and does not rebuild the agent table. That is unchanged and
  pre-existing for configured rows; a preset row has no roster entry to rebuild.
• The pre-submit sweep found three defects in this branch's own code and each is fixed in its
  own commit: the page's leading comment still declared "two verbs on a row, and only two"
  after a third state was added; the preset filter resolved commands against this process's
  PATH while _probe_acp answers the row on screen from the login shell's; and the scheduler's
  early return had to go, because whether any shipped preset is on this machine cannot be
  answered from the synchronous side.

Type

• Fix
• Feature
• Docs
• CI / tooling
• Refactor
• Other

Verification

Run in a worktree at this branch's head, rebased onto 8d74fb9.

• uv run --frozen --all-extras pytest tests/test_subagent_probe.py tests/test_subagent_acp.py tests/test_rpc_subagents.py tests/test_rpc_schema_match.py tests/test_subagent_acp_mcp_lifecycle.py tests/test_acp_unprompted.py tests/test_subagent_manager.py tests/test_acp_backend_cwd.py tests/test_subagent_third_party.py -q -p no:randomly -- 1157 passed.

• npx vitest run src/features/xa/ in ui-web -- 91 passed.

• Full ui-web suite, serially, with the localstorage flag this box needs -- 1840 tests, 2
  failed, 0 unhandled errors. Both failures are in src/features/workspace/, which this branch
  does not touch, and the failing ID set is identical to the one recorded before any of this
  work. They are an artifact of node v26 shadowing happy-dom's localStorage on this machine.

• make lint-python lint-imports lint-types lint-ui lint-tui -- all pass. lint-bridge fails on
  a TypeScript deprecation in bridge/tsconfig.json; it fails identically on an untouched
  checkout and this branch does not touch bridge/.

• make check-commits check-large-files check-source-language with the three-dot range -- all
  exit 0.

• Seventeen new tests, fourteen python and three in the page's own suite. Every one was
  watched failing for the missing behaviour before the code that answers it was written,
  except the three that cover already-written defensive branches, which are verified by the
  coverage measurement below instead. The test_cancel regression that guards the in-flight lock was proved
  load-bearing by widening the lock to the whole row and watching it go red.

• Review round one, two blocking findings, both reproduced here before being fixed and both
  re-run afterwards. needs_auth from the advertisement alone: forcing the message heuristic to
  False left needs_auth true against the stub, and the stub gained a no_session_other mode
  because every existing refusal mode refuses in auth-shaped words, so no test could separate
  the two halves. The unrecoverable row: a recorded refusal, then run_test(source="preset")
  returning ok, then the same snapshot still reading needs_auth true; it now reads false and
  ready. Re-measured against the real agents afterwards, Grok Build still reports needs_auth
  true and CodeBuddy still ready.

• The diff-coverage gate read 88.00% on the first head. Of the 120 lines this branch adds to
  probe.py, none is now uncovered; the four that remain in that file are the base's own.

• A second sweep over the review-fix commits found one more defect, fixed in its own commit: a
  test comment still gave the removed gate as the reason for an assertion that stands for a
  different one.

• End to end against real agents on this machine: the backfill reaches the 9 presets that are
  installed and skips Copilot, Qwen and Kimi, which are not; verify reports CodeBuddy ready
  with needs_auth false and Grok Build attention with needs_auth true; and the rows come back
  reading ready/false, missing/false and attention/true respectively.

• Relevant tests pass locally

• Relevant lint / type checks pass locally

• User-facing docs or screenshots are updated when needed

No docs change: the agents page carries no user-facing documentation page, and the two new
strings are catalogue entries.

Risk

User-visible behaviour changes, all on the agents page and its server surface:

• A Connect press disables its own button until the call returns. A second press for the same
  row is dropped client-side rather than sent.
• A row whose command is not on the machine, and a row whose agent asked to be signed in, no
  longer offer Connect. They show a word and are not pressable. The way back for the second is
  the card's Test.
• A gateway start now handshakes the installed shipped presets once, in the background.
• subagents.list rows gain needs_auth. It is optional on the wire and defaults false, so a
  client that does not read it behaves exactly as before.

Rollback is the revert of this squash commit: nothing here migrates data, and a snapshot row
recorded by the widened backfill is re-derived or ignored by the previous code, which reads the
same store and simply never wrote those rows.

• Security impact considered
• Backward compatibility considered
• Rollback path is clear for risky changes

Related Issues

N/A

[gloryfromca]

Blocking: needs_auth can be falsely assigned and can remain permanently stale after sign-in.

I found two blocking paths, marked inline. I covered the full diff, the UI/RPC/runtime callers, the relevant history, AGENTS.md and context-map constraints, backward compatibility of the wire field, connection-pool architecture, and whether tests were weakened. The added tests are meaningful, but neither failure path below is covered.

Verification on this head: uv run pytest tests/test_subagent_probe.py tests/test_subagent_acp.py tests/test_rpc_subagents.py tests/test_rpc_schema_match.py -q passed (722); npm test -- src/features/xa passed (91); npm run type-check passed; npm run gen:check passed (178 methods). git diff --check github/main...HEAD also passed.

[gloryfromca]

No blockers; this can merge as far as I am concerned.

The two prior blockers are fixed and their threads are resolved. I reviewed the rebased full diff and the four new fix/test commits, including the UI-to-RPC-to-snapshot recovery path, connection-pool behavior, project rules and context terms, history, wire backward compatibility, and whether tests were weakened. I found no new defect worth raising.

Verification on this head: uv run pytest tests/test_subagent_probe.py tests/test_subagent_acp.py tests/test_rpc_subagents.py tests/test_rpc_schema_match.py -q passed (726); npm test -- src/features/xa passed (91); npm run type-check passed; npm run gen:check passed (178 methods); git diff --check github/main...HEAD passed; and the merge-tree check against current github/main was clean.

[0xKT]

Not a blocker. The split this PR draws is the right one, and the private
pool in ping_agent fixes a real collision. Three observations about what
happens to a needs_auth after it is written, none of which holds the PR. Read
on head 9d06def against base 0cb8b79.

1. A recorded needs_auth is a one-way latch, and the per-boot re-measure cannot clear it

Two new lines, read together:

probe.py:678  if snapshot is not None and not snapshot.stale
                 and not getattr(snapshot, "needs_auth", False): continue
probe.py:685  if result.status == "ready" or getattr(result, "needs_auth", False):
                  store.record(result)

The first makes a needs_auth snapshot permanently un-fresh, so it is
re-verified at every boot -- a child process each time, which the comment above
it argues is worth paying. The second is the only door to record, and it is
open for exactly two outcomes. So the one case the re-measure exists to catch --
the agent is no longer refusing over a credential -- is discarded unless it
comes back fully ready. An agent that now fails for a plainly different reason
leaves needsAuth: true on disk, and the row keeps rendering a disabled
"Unauthorized" for a verdict the code measured to be wrong and threw away, one
process per boot, forever.

Measured through schedule_snapshot_verification with the real store and a real
child adapter, launch fingerprint held constant so the snapshot compares as
fresh rather than stale:

installed, never signs in        boot 1..5   spawns=1 each, needsAuth stays true
CONTROL: an agent that passes    boot 1 spawns=1, boots 2..5 spawn=0
latch: refusal changes to a
  non-credential one             boots 1..3  spawns=1 each, needsAuth stays true
CONTROL: re-measure comes
  back ready                     boot 2 clears it, boot 3 spawns=0

The control matters: a passing agent is skipped after the first boot, so the
repetition is the new not needs_auth clause and not the harness.

The way out exists -- the card's Test records unconditionally
(probe.py:536) and canTest is !builtin && !vendored, so the row can be
cured by hand, which is why this is not blocking. But the label the user is
shown says "Unauthorized", which tells them to go and sign in; signing in is
exactly what will not help, because the launch config has not moved and the
boot-time path cannot write the cure.

The input that puts a row into this state is _looks_like_auth, now
load-bearing for a persisted field. It is a substring match over
("auth", "unauthor", "credential", "api key", "apikey", "login", "401"), so
.../scratch-4012/... (a path), unknown author field and
/bin/login-shell-wrapper exited 127 all read as credential refusals. Being
fair about the evidence: those three are constructed, and against the shipped
adapters no false positive appeared -- Claude Code and Codex came back ready,
and Pi's "executable not found" correctly gave needs_auth=False. The latch is
measured; the trigger is, so far, hypothetical.

2. A stale snapshot's needs_auth is served as a present-tense verdict

acp_snapshot_for loads with allow_stale=True and logs a warning when what it
returns is stale. subagents.py:342 then emits
bool(getattr(caps, "needs_auth", False)) with no stale guard between them, and
XaPage.tsx:137 turns it into the unauthorized stage, which :180-183 renders
as a disabled button. For the same row, base served off with a Connect button:
a control the reader had is withdrawn on the strength of a measurement the code
itself has already flagged as taken against a launch config the agent no longer
has.

The page has a stale stage and uses it elsewhere (:347), so the distinction
exists here -- it just is not consulted on this path.

One more ordering detail: :136-138 returns unauthorized before :139's
if (!row.configured) return 'add', so an unconfigured preset row that picked up
a latched needs_auth from the new boot-time verify loses its Add button, not
only its Connect.

3. An unconfigured preset that comes back neither ready nor unauthorized is retried every boot with no memory of having tried

Same two lines as (1), from the other side. A preset has no snapshot, so :678
never skips it; if verify_agent returns anything but ready or a credential
refusal, :685 writes nothing, and the next boot is identical. For a preset whose
command is an npx -y <pkg>@<ver> fetch, that is the fetch paid again at every
gateway start, with nothing on disk to show for it. Measured: three boots, three
npx -y pi-acp@0.0.33 spawns, snapshot file unchanged.

Recording the failure is not obviously right either -- the comment at :681-684
explains why not, and it is a good reason. But the two decisions together leave
a class of row that is re-probed forever and never settles, and nothing bounds
the repetition.