hyp status tells an OTEL-attached machine to run hyp attach claude to restore CA trust, which that path deliberately never does

[philcunliffe]

Problem

On a machine whose Claude attach is otel, hyp status prints a proxy-trust
repair that cannot work:

  proxy trust:
    ca fingerprint: F0:F5:4B:...
    login keychain: not trusted - Remote Control inbound will not work, run `hyp attach claude` to retry
    launchd env:    NODE_USE_SYSTEM_CA not set - run `hyp attach claude` to set it

The warning is correct: with the CA untrusted, Remote Control inbound really
does not work. The repair is stale. The otel attach path deliberately
touches neither the keychain nor the launchd environment
(LLP 0258#nothing-else:
"no keychain, no launchctl setenv, no LaunchAgent on this path"), and otel is
now the claude client's only attach mode. So a user who follows the instruction
runs hyp attach claude, sees it report success, re-runs hyp status, and gets
the identical two lines back with nothing changed.

This is reachable by the documented migration route, not an exotic state:
hyp attach claude on a proxy machine migrates it to otel and prints
"Run hyp detach claude --purge to remove it". Doing exactly that leaves the
machine in this state permanently.

Reproduction

Observed on macOS, HypAware at master 8f740a3f.

1. On a machine with a proxy-mode claude attach, run hyp detach claude --purge
   (removes the CA, its login-keychain trust, NODE_USE_SYSTEM_CA, and the
   login agent).
2. Restart the daemon, letting it re-attach claude in otel mode. The gateway
   mints a fresh, untrusted CA.
3. hyp status.

Observed: both remediation lines name hyp attach claude. Running it changes
neither the keychain nor the launchd env, and status is unchanged afterward.

Expected: on a machine with no proxy-mode client attach, either name a command
that actually restores trust, or say plainly that trust is not restored by
attach any more and name what a user should do if they want Remote Control
inbound back.

Code path

src/core/commands/status.js:689

return 'not trusted - Remote Control inbound will not work, run `hyp attach claude` to retry'

and the sibling launchd-env line. Both are emitted without consulting the
client's attach mode, so they still assume the pre-LLP-0262 world in which
hyp attach claude was the command that established proxy trust.

Notes for whoever picks this up

• The lines are not simply dead. Codex, OpenClaw, Hermes, Claude Desktop, and
  raw SDK traffic still route through the gateway, and Remote Control inbound
  still wants the trusted CA. On this machine those clients were unaffected by
  the purge only because they target http://127.0.0.1:18521 with no TLS. So
  the fix is to make the remediation honest about who can restore trust, not to
  delete the section.
• Whether some command should be able to re-establish trust without a proxy
  attach (Remote Control inbound being the remaining consumer) is a design
  question worth settling before wording the line, and may deserve its own
  decision LLP rather than being decided inside a status-string fix.

[philcunliffe]

Picked this up as a defect fix and stopped at the escalation line the issue's
own last bullet draws. The mechanical half is free; the wording half is a
design call that I should not make unilaterally inside a status string. Detail
and options below, all read off master at ec3361bb.

What I was doing

Worktree off origin/master, read LLP 0232 / 0237 / 0238 / 0239 / 0258 / 0262
and the sanitizeLabel contract (LLP 0225), then traced both remediation
strings back to what could satisfy them. I got as far as a precise diagnosis
and then could not write a regression test, because I could not state what the
correct rendered advice is without picking a design.

What the code actually says

The two strings:

• src/core/commands/status.js:689 - 'not trusted - Remote Control inbound will not work, run `hyp attach claude` to retry'
• src/core/commands/status.js:702 - `${ENV_VAR_NAME} not set - run \`hyp attach claude\` to set it`

Three findings, and the third is the blocker

1. The issue understates the problem: it is not that hyp attach claude
stopped restoring trust, it is that nothing restores it.

installCaTrust (src/core/tls/darwin_trust.js:77) and installLaunchdEnv
(src/core/daemon/launchd_env.js:96) have zero production callers on
master. The only files that reference either are their own definition and
their unit tests (test/core/tls-darwin-trust.test.js,
test/core/launchd-env.test.js). claude was the only client that ever
attached by proxy, and its attach now hardcodes the mode
(hypaware-core/plugins-workspace/claude/src/index.js:231, mode: MODE_OTEL,
under the // @ref LLP 0258#nothing-else annotation at line 224). So there is
no "name a command that actually restores trust" branch available: the set of
such commands is empty, product-wide, not just for the claude client.

That is the exact condition the issue flags as needing a decision, so I am
raising it rather than inventing a repair.

2. The consequence clause is now suspect too, not just the repair clause.

LLP 0262 R6 (llp/0262-otel-attach-replaces-proxy.rfc.md:106): "Remote Control
untouched. The base URL is never repointed and no proxy is set, so the
first-party predicate holds trivially." On an OTEL-attached machine Claude Code
does not traverse the gateway at all, so its Remote Control SSE transport never
meets the interception CA and an untrusted CA cannot break it. The issue's
report asserts the warning half is correct ("with the CA untrusted, Remote
Control inbound really does not work"); LLP 0262 R6 says the opposite for
exactly the machine described. I cannot settle that from the repo, and it
changes what the replacement sentence should say: if Remote Control is fine,
the line has no consequence left to warn about and the honest render may be
"nothing here is degraded", which is close to suppressing the block.

3. Writing the raw security incantation instead is closed off.

The obvious "just tell them how" repair contradicts an Accepted decision:
LLP 0237 Options, item 3 ("Instruct the user to run the command") was rejected
because it "turns onboarding into copy-pasting a security incantation, which
is the exact experience this decision exists to remove."

Not a blocker: the plumbing PR #800's "Still open" bullet says is missing
("gating the launchd env: line on 'a proxy attach is live' needs mode
plumbed out of the attach probe into ClientAttachReport") already exists on
master - src/core/daemon/types.d.ts:229 declares mode, and
src/core/daemon/status.js:1109 fills it from the marker
(src/core/daemon/status.js:1197 already gates the capture-health section on
probe.mode === 'otel'). So whichever wording is chosen, the gate is a small
change. Only the wording is open. collectProxyTrust
(src/core/daemon/status.js:1556) gates the block on darwin plus a CA on disk
and never consults attach mode, which is where the gate would go.

Options

A. Drop the repair clause, keep the state. Renders
login keychain: not trusted / launchd env: NODE_USE_SYSTEM_CA not set with
no instruction. Honest and minimal, contradicts nothing. Costs the block its
actionability, and leaves finding 2 unresolved (does the "Remote Control
inbound will not work" half stay?).

B. Gate the block on a live proxy-mode attach. Render proxy trust: only
when some attached client reports mode === 'proxy'; hide it otherwise. Most
faithful to "these are proxy mode's two invisible preconditions" (LLP 0237
Consequences, LLP 0239). But nothing can reach mode === 'proxy' on master, so
in practice this deletes the block, and the issue explicitly says "the fix is
to make the remediation honest about who can restore trust, not to delete the
section."

C. Keep the block, reword to name the only command that changes this state:
hyp detach claude --purge. True (it removes the CA and its trust) but it is
the opposite of a repair, and it is what the LLP 0262 migration note already
prints, so status would be echoing an unwind as if it were a fix.

D. Restore a trust-granting command (e.g. re-add the trust step behind
hyp gateway proxy enable, or a new hyp gateway trust-ca), so the string can
name something real again. This is what LLP 0237's Extended-by line assumes
still exists - "this decision governs the clients still proxied"
(llp/0237-attach-trusts-ca-in-login-keychain.decision.md:9-12) - and what
src/core/commands/clients.js:906 still promises out loud ("macOS will then ask
to trust the HypAware Local CA"). New surface; wants its own decision LLP.

I have LLP 0275 reserved and can write whichever of these up as a decision plus
the code, in one tick, once the call is made.

Questions

1. Which option? A, B, C, D, or something else.
2. Is finding 2 right? On an OTEL-attached machine with gateway proxy_mode
   on and no proxy-attached client, does an untrusted CA break anything the user
   can observe? If the answer is "no", the block on that machine is reporting a
   precondition for a mode nothing is in, and A/B change meaning substantially.
3. If D: should granting trust be reachable without an attach at all, given
   that the remaining consumers of the interception CA are gateway proxy_mode
   clients rather than claude?

Note on collision: src/core/commands/status.js and
test/core/status-proxy-trust.test.js are both touched by PR #800, and the
gating question is PR #800's own "Post-detach repair prompt (low)" still-open
bullet, so whoever lands this should expect to rebase over it. I have touched
neither PR #800's nor PR #822's branch.

Reply with a comment on this issue; neutral monitors this thread and will
re-engage with your guidance on its next tick.

[philcunliffe]

Implemented by PR #902. Status no longer offers a Claude proxy/CA repair that the OTEL-only attach path cannot perform.