On a joined host with @hypaware/openclaw enabled, hyp status reports three things that can never resolve:
clients:
- openclaw [configured, not attached] [local]
client actions:
- attach openclaw [pending]
diagnostics:
[WARN ] client_attach_missing: '@hypaware/openclaw' is enabled but openclaw settings show no HypAware marker - run 'hyp attach --client openclaw'
Nothing is actually broken: routing is owned by the steering plugin (LLP 0152 / 0159) and the adapter intentionally declares no attachProbe and writes no marker (LLP 0143). But the pending is permanent, the not attached rendering is misleading (the honest answer is "not applicable"), and the printed repair is inert: hyp attach --client openclaw resolves the adapter's deliberate no-op (hypaware-core/plugins-workspace/openclaw/src/index.js, the LLP 0143 block) and writes no marker either, so running it clears nothing. Raised post-merge on PR #510 (#510 (comment)).
Root cause: status derives declared-attach targets by a different rule than the reconciler
The reconciler's desired() skips probe-less descriptors, exactly as LLP 0143 intends:
// src/core/config/action_attach.js:114
if (!descriptor.attachProbe) continue
So no attach target is ever emitted for openclaw, perform() never runs, and no marker is ever written. But three status surfaces derive against the attach contract without that gate:
buildClientActionsReport builds declaredAttach from every enabled client descriptor on a joined host, with no attachProbe check (src/core/daemon/status.js:889-901); at status.js:945-947 no marker + declared + hasCentral resolves to pending, permanently.
- The clients row maps a probe-less descriptor to
{ attached: false } (status.js:591-593), rendering not attached where nothing is attachable.
- The
client_attach_missing diagnostic fires on configured && !probe.attached, ungated (status.js:604), and its fallback repair is the inert generic attach when the picker declares no configure_command.
The doc comment above buildClientActionsReport already states the intended invariant, "pending / n/a are derived for declared targets the reconciler would act on but has not yet", so this is a missed gate, not a design choice.
Not new to PR #510
attach claude-desktop [pending] shows the same way, since Desktop dropped its probe first (LLP 0115 #no-attach-on-join, #444 / #445). The OpenClaw adapter just makes it a second instance.
Suggested fix
Gate all three surfaces on descriptor.attachProbe: a probe-less client renders n/a rather than pending, is not shown as not attached, and does not raise client_attach_missing. That keeps status agreeing with desired() the same way readAttachPolicy / readBackfillPolicy already keep the two sides from disagreeing about on_join.
Refs: LLP 0044 (attach status surface), LLP 0143 (no attach probe for openclaw), LLP 0115, #444, #445, PR #510.
On a joined host with
@hypaware/openclawenabled,hyp statusreports three things that can never resolve:Nothing is actually broken: routing is owned by the steering plugin (LLP 0152 / 0159) and the adapter intentionally declares no
attachProbeand writes no marker (LLP 0143). But thependingis permanent, thenot attachedrendering is misleading (the honest answer is "not applicable"), and the printed repair is inert:hyp attach --client openclawresolves the adapter's deliberate no-op (hypaware-core/plugins-workspace/openclaw/src/index.js, the LLP 0143 block) and writes no marker either, so running it clears nothing. Raised post-merge on PR #510 (#510 (comment)).Root cause: status derives declared-attach targets by a different rule than the reconciler
The reconciler's
desired()skips probe-less descriptors, exactly as LLP 0143 intends:So no attach target is ever emitted for openclaw,
perform()never runs, and no marker is ever written. But three status surfaces derive against the attach contract without that gate:buildClientActionsReportbuildsdeclaredAttachfrom every enabled client descriptor on a joined host, with noattachProbecheck (src/core/daemon/status.js:889-901); atstatus.js:945-947no marker + declared +hasCentralresolves topending, permanently.{ attached: false }(status.js:591-593), renderingnot attachedwhere nothing is attachable.client_attach_missingdiagnostic fires onconfigured && !probe.attached, ungated (status.js:604), and its fallback repair is the inert generic attach when the picker declares noconfigure_command.The doc comment above
buildClientActionsReportalready states the intended invariant, "pending / n/a are derived for declared targets the reconciler would act on but has not yet", so this is a missed gate, not a design choice.Not new to PR #510
attach claude-desktop [pending]shows the same way, since Desktop dropped its probe first (LLP 0115 #no-attach-on-join, #444 / #445). The OpenClaw adapter just makes it a second instance.Suggested fix
Gate all three surfaces on
descriptor.attachProbe: a probe-less client rendersn/arather thanpending, is not shown asnot attached, and does not raiseclient_attach_missing. That keeps status agreeing withdesired()the same wayreadAttachPolicy/readBackfillPolicyalready keep the two sides from disagreeing abouton_join.Refs: LLP 0044 (attach status surface), LLP 0143 (no attach probe for openclaw), LLP 0115, #444, #445, PR #510.