Surfaced by the round-2 review of PR #594; low severity, deliberately not blocking that PR.
The case
src/core/cli/walkthrough.js:906-913 treats a picked client with no entry in the gateway registry as not applicable to the attach lane, recording {ok: true, noAdapter: true} and printing nothing. That is correct for @hypaware/claude-desktop, which declares contributes.client purely for skill_dir/agent_dir plumbing and deliberately registers no runtime adapter (@ref LLP 0115#no-attach-on-join).
But the discriminator is runtime absence from the registry, not declared intent, and those are not the same thing. activatePlugins tolerates a failed activation (src/core/runtime/loader.js:108-119: the error is logged, results.push({ok: false, ...}), boot continues). So a plugin whose activate() throws registers no client either, and its picked row now goes silent in the finale where before PR #594 it printed attach: <client> failed.
This applies to claude, codex and openclaw, not just to genuinely adapterless plugins.
Why it is low, not blocking
What a fix needs
An honest discriminator for "declared adapterless" versus "should have had an adapter and does not". Options, none obviously right, which is why this is a follow-up rather than a review-time edit:
- consult the picker row's
configure_command / needs_setup, which is how claude-desktop already advertises that its setup lives elsewhere
- consult the activation results from
activatePlugins, so a failed activation is distinguishable from one that never intended to register
- have the manifest state attachability separately from
contributes.client, which currently means both "attachable client" and "owns skill/agent dirs"
The third is the root cause and the largest change.
Adjacent, same area
The noAdapter branch emits no log or span attribute, so nothing records the decision anywhere. The whole attach lane has no structured logging today, so this is consistent rather than a new regression, but per CLAUDE.md's log-driven-development section it is a lane worth instrumenting: a silent skip that is indistinguishable from "nothing happened" is exactly what that section asks workflows to avoid.
Depends on #594 landing (the noAdapter branch does not exist on master until then).
Surfaced by the round-2 review of PR #594; low severity, deliberately not blocking that PR.
The case
src/core/cli/walkthrough.js:906-913treats a picked client with no entry in the gateway registry as not applicable to the attach lane, recording{ok: true, noAdapter: true}and printing nothing. That is correct for@hypaware/claude-desktop, which declarescontributes.clientpurely forskill_dir/agent_dirplumbing and deliberately registers no runtime adapter (@ref LLP 0115#no-attach-on-join).But the discriminator is runtime absence from the registry, not declared intent, and those are not the same thing.
activatePluginstolerates a failed activation (src/core/runtime/loader.js:108-119: the error is logged,results.push({ok: false, ...}), boot continues). So a plugin whoseactivate()throws registers no client either, and its picked row now goes silent in the finale where before PR #594 it printedattach: <client> failed.This applies to
claude,codexandopenclaw, not just to genuinely adapterless plugins.Why it is low, not blocking
hyp status'sclient_attach_missingdiagnostic remains the backstop.attach: claude-desktop failedfor something that was never attachable.What a fix needs
An honest discriminator for "declared adapterless" versus "should have had an adapter and does not". Options, none obviously right, which is why this is a follow-up rather than a review-time edit:
configure_command/needs_setup, which is howclaude-desktopalready advertises that its setup lives elsewhereactivatePlugins, so a failed activation is distinguishable from one that never intended to registercontributes.client, which currently means both "attachable client" and "owns skill/agent dirs"The third is the root cause and the largest change.
Adjacent, same area
The
noAdapterbranch emits no log or span attribute, so nothing records the decision anywhere. The whole attach lane has no structured logging today, so this is consistent rather than a new regression, but perCLAUDE.md's log-driven-development section it is a lane worth instrumenting: a silent skip that is indistinguishable from "nothing happened" is exactly what that section asks workflows to avoid.Depends on #594 landing (the
noAdapterbranch does not exist on master until then).