Merge origin/master into fix/issue-885

Three textual conflicts, all resolved by keeping both sides:

- docs/PRIVACY.md: master's disclosure of the launchd LaunchAgent stays,
  re-tensed as residue of the proxy-attach releases to match this branch's
  "nothing installs the CA into a system trust store any more"; the lifetime
  paragraph keeps master's added facts (permitted hosts, launchd variable)
  inside this branch's wording about detach and the grant.
- src/core/commands/status.js: master's describePermittedHosts is kept
  verbatim; describeLaunchdEnv keeps this branch's doc comment explaining
  why it states rather than prescribes.
- src/core/daemon/status.js: collectProxyTrust takes both master's
  timeout-bounded probes and this branch's `config` argument, and returns
  both `hosts` and `proxyModeConfigured`.

One semantic conflict, from master's #817 pinning the `--json` shape of the
migration pointer against `claude` while this branch stops the claude row
declaring `compose.gateway_proxy_mode`. Both pins are kept by driving them
through the staged picker row that still declares proxy attach, the way this
branch already converted the rest of the file, plus a new pin that a `--json`
claude attach on a TTY carries no pointer either.

LLP 0251 gains the `Extended-by: LLP 0262` forward-ref LLP 0243 already
carried, since its section 2 names the claude declarers this branch removes.

Author: test

README.md

@@ -338,10 +338,25 @@ Such a client is then pointed at the gateway with `HTTPS_PROXY` and
   with that inbound channel off. No admin rights are needed and the
   machine-wide system keychain is not touched. On other platforms trust
   stays file-scoped to the client's own settings. `hyp status` shows the
-  fingerprint and whether the keychain still trusts it.
-  `hyp detach <client>` keeps the CA and the trust, so re-attaching does not
-  ask again; `hyp detach <client> --purge` and `hyp daemon uninstall` remove
-  both.
+  fingerprint, every host the CA is permitted to vouch for, and whether the
+  keychain still trusts it. `hyp detach <client>` keeps the CA and the
+  trust, so re-attaching does not ask again; `hyp detach <client> --purge`
+  and `hyp daemon uninstall` remove both.
+- **On macOS, a proxy attach also leaves a login-session variable behind.**
+  Bun picks its trust store before any settings file is read, so a keychain
+  root only counts if `NODE_USE_SYSTEM_CA=1` is already in the process
+  environment. The attach that trusted the CA therefore ran `launchctl
+  setenv NODE_USE_SYSTEM_CA 1` and installed a small LaunchAgent,
+  `~/Library/LaunchAgents/com.hyperparam.hypaware.node-system-ca.plist`,
+  whose only job is to re-run that command at each login. It stays a login
+  item on your machine until it is removed, and it is a session-wide
+  variable that other Node programs read too. `launchctl setenv` reaches
+  processes launched after it, so a terminal app that was already running
+  must be fully quit and reopened. `hyp detach <client>` unsets the
+  variable and removes the agent, as do `hyp detach <client> --purge` and
+  `hyp daemon uninstall`; `hyp attach claude` unwinds it when it migrates a
+  previously proxied machine; and `hyp status` shows whether the variable is
+  currently live.
 - **Only the hosts a registered upstream names are decrypted.** Every other
   host the client talks to is tunnelled through without being decrypted.
 - **What gets recorded does not change.** Only the recorded API paths are

docs/PRIVACY.md

@@ -78,12 +78,27 @@ those, that trust setting is still on your account until you remove it, and
 `hyp status` says so. It never needed admin rights, and the machine-wide
 system keychain and other user accounts were never modified.
 
-**Its lifetime.** `hyp status` shows the fingerprint and, on macOS, whether
-the login keychain still trusts it. `hyp detach claude` deliberately leaves
-the CA and any trust from an earlier release in place, because a detach is
-not a statement about the certificate and no attach re-creates the grant;
-`hyp detach claude --purge` and `hyp daemon uninstall` remove the CA and its
-keychain trust.
+**What an earlier macOS attach also left behind.** The keychain root only
+takes effect if `NODE_USE_SYSTEM_CA=1` is in the environment before Claude
+Code starts, so the proxy attach of those releases also ran
+`launchctl setenv NODE_USE_SYSTEM_CA 1` and installed a LaunchAgent at
+`~/Library/LaunchAgents/com.hyperparam.hypaware.node-system-ca.plist` that
+re-ran that one command at each login. What it runs is `/bin/launchctl`
+itself, once, which sets the variable and exits: there is no resident
+process, no HypAware code in it, and nothing is sent anywhere. It is still a
+login item on your machine, and a session-wide variable that other Node
+programs will also read. Attaching today installs neither, but if you ran one
+of those releases both are still there; `hyp detach claude` unsets the
+variable and removes the agent, as do `hyp detach claude --purge` and
+`hyp daemon uninstall`.
+
+**Its lifetime.** `hyp status` shows the fingerprint, every host the CA is
+permitted to vouch for, and, on macOS, whether the login keychain still
+trusts it and whether the launchd variable is live. `hyp detach claude`
+deliberately leaves the CA and any trust from an earlier release in place,
+because a detach is not a statement about the certificate and no attach
+re-creates the grant; `hyp detach claude --purge` and `hyp daemon uninstall`
+remove the CA and its keychain trust.
 
 ## Where it goes
 

hypaware-core/plugins-workspace/ai-gateway/src/source.js

@@ -432,17 +432,23 @@ async function prepareInterception(ctx, config, upstreams, liveState) {
   if (!config.proxyMode) {
     // Proxy mode is off, but a CA on disk means a client was attached in proxy
     // mode at some point and may still have `HTTPS_PROXY` pointing here. Serve
-    // blind tunnels so its egress keeps working, and say so loudly: the repair
-    // is a re-attach (or a detach), and nothing else on the machine will
-    // volunteer that.
+    // blind tunnels so its egress keeps working, and say so loudly: nothing
+    // else on the machine will volunteer that this install is in the degraded
+    // state. A plain re-attach is NOT the remedy: attach leaves the CA where
+    // it is on purpose (the trust is offered back, never taken), so the file
+    // that puts the install in this state survives the re-attach. The
+    // remedies that land are removing the CA (`hyp detach claude --purge`,
+    // then re-attach) or turning `proxy_mode` back on.
+    // @ref LLP 0262#migration [constrained-by]: attach offers the CA back rather than removing it, so it cannot clear this state on its own
     const stale = await readLocalCaInfo({ stateRoot: defaultStateRoot(ctx.env) })
     if (stale) {
       liveState.interceptionError = 'proxy_mode is off but a local CA is installed'
       ctx.log.warn('aigw.proxy_mode_stale_ca', {
         [Attr.PLUGIN]: PLUGIN_NAME,
         ca_cert_path: stale.certPath,
         reason: 'serving blind tunnels so an already-attached client keeps working; ' +
-          'run `hyp attach claude` to move it back to base-URL mode, or `hyp detach claude`',
+          're-attaching leaves this CA on disk, so run `hyp detach claude --purge` ' +
+          'and re-attach to clear the proxy residue, or turn proxy_mode back on',
       })
       return { tunnelOnly: true }
     }