Collapse the session opt-out skills onto `hyp session` and update LLP 0066/0067 (blocked by #432)

[bgmcmullen]

Blocked by #432 (which adds hyp session ignore|unignore|status). This issue is the consequence: once the verb exists, the client skills stop being implementations and become thin invocations, and two LLPs stop being true.

Current state

hypaware-ignore and hypaware-unignore (Claude only) are ~60 lines of embedded bash each: an env guard, gateway endpoint resolution, curl, and a python3 JSON parse. Branch skills/ignore-hide-and-destale fixes what was outright wrong in them today (see below), but the mechanism itself only goes away with the verb.

Fixed in-place on that branch, pending the verb:

• Endpoint resolution was ${ANTHROPIC_BASE_URL:-http://127.0.0.1:8787}; 8787 has not been the default since LLP 0114 (see hyp init writes an explicit listen: 127.0.0.1:8787, forfeiting LLP 0114's fixed default and its EADDRINUSE fallback #431). Now resolves the live port from hyp status --json with an 18521 default. This block is throwaway the moment the verb lands.
• hypaware-ignore printed .total and declared success without ever checking ignored. Now requires ignored: true and reports "still being recorded" otherwise.
• hypaware-unignore said "The CLI is idempotent" (there is no CLI) and told users to hand-delete a .hypignore that hyp unignore <path> manages, omitting the machine-local governor (hyp policy unset / hyp policy show) entirely.
• Both gained disable-model-invocation: true, which removes them from the model's context while leaving /hypaware-ignore in the user's slash menu.

Target state

Each skill body becomes a single dynamic-context injection:

---
name: hypaware-ignore
description: Stop HypAware recording for this session
disable-model-invocation: true
allowed-tools: Bash(hyp session ignore*)
---

!`hyp session ignore`

Report the line above. Check at any time with `hyp session status`.

Deletes per file: the env guard (the verb resolves the id), the endpoint block (the verb resolves the endpoint from config + status.json), the curl, and the python3 parse. Roughly 60 lines to 5. The allowed-tools grant also narrows from Bash(curl *) to Bash(hyp session ignore*), which is a real reduction in what the skill pre-approves.

Codex gets the skills for the first time

hypaware-core/plugins-workspace/codex/skills/ currently has no hypaware-ignore / hypaware-unignore, so a Codex user has no session opt-out outside hypaware-privacy Step 1 (see the Codex comment on #432). Adding them was previously unattractive because it meant duplicating the rollout-resolution bash; with the verb owning resolution, the Codex skills are the same five lines as the Claude ones.

Register in both plugins: hypaware-core/plugins-workspace/claude/src/index.js (the skill-name list at ~L248) and the equivalent in codex/src/index.js.

LLP edits that must land in the same change

These are currently false-once-implemented, not merely stale:

• LLP 0066 §motivation ("This spec closes that gap without changing the skills. The skills are the contract; the implementation is specified here.") and LLP 0067 (front matter: "The skill ... is the contract and is not changed"; §overview: "Nothing touches the cache schema, the recorder, backfill, or the skills"). After this change the route remains the contract and the CLI becomes its primary client, with the skills as thin wrappers. Reword rather than delete: the point being preserved is that the wire contract was designed first and honored, not that the skill file is immutable.
• LLP 0067 §drop justifies R5 with "the hash fallback it uses otherwise can never be in the set (the skill only ever submits a real CLAUDE_CODE_SESSION_ID)". A verb accepting an explicit [id] argument weakens that invariant: a user can submit an arbitrary string. Either document that the set may hold ids that match nothing (harmless: membership is tested against resolved ids), or have the verb validate the id shape. Decide and record it.

Acceptance

• Both Claude skills are <10 lines and contain no curl, no python3, no port literal.
• Codex has both skills, registered and materialized at attach.
• /hypaware-ignore still works end to end; hyp session status confirms membership afterwards.
• disable-model-invocation: true retained on all four (they are user-triggered, side-effecting actions).
• LLP 0066 / 0067 edits land in the same commit as the code, per the repo's living-docs rule.
• /ref-check clean.

Related

• Session opt-out fails open and cannot be checked: restart and session-resume both silently resume recording; add hyp session ignore/unignore/status #432 (the verb; blocks this), hyp init writes an explicit listen: 127.0.0.1:8787, forfeiting LLP 0114's fixed default and its EADDRINUSE fallback #431 (the port pin that made the stale fallback visible)
• LLP 0066, 0067 (session opt-out), LLP 0107 (skills ride attach), LLP 0138 (client assets, one materializer)

[philcunliffe]

🤖 neutral: PR #518 will make the skill-script fail-open real - this issue owns the file

Recording here rather than filing a new issue, since #435 owns the skill scripts and retires them.

What changes on merge. PR #518 (issue #499) fixes a genuine fail-open in the CLI: readRolloutMeta's if (meta?.threadId === undefined) return undefined collapsed "not a session_meta header" together with "a header stating cwd + container but no payload.id", so the cwd scan's count ("exactly one rollout records this cwd") silently lost evidence. On origin/master today, two session_meta headers stating the same cwd, one without payload.id, resolve to {"ok":true,"sessionId":"C2",...} - hyp session ignore then opts out one of two indistinguishable sessions and prints success. #518 makes the CLI refuse that as ambiguous.

The gap. codex/skills/hypaware-privacy/SKILL.md:72 carries the identical pre-count filter and is not touched by #518. So after merge the two surfaces diverge on the same input: the CLI refuses, the script resolves and POSTs. This is exactly the divergence round 4 of PR #456 predicted; issue #499 §1 then recorded it as "not a divergence" because both surfaces agreed. That record becomes false on merge.

The #518 reviewer demonstrated both sides (running a verbatim port of the filter, since python3 is absent on this host) and deliberately did not rewrite the skill: the filter has been declined twice on purpose, and this issue retires the script entirely. #518 landed a doc fix instead (a6f0112), so LLP 0067 §cli-session-id now names the skill body as the exception to the new counting rule, names the fixture that separates the surfaces, and names #435 as the owner.

Why it matters here. Until this issue lands, the skill path can still opt out the wrong session and report success - a privacy-relevant false confirmation. That is an argument for the collapse onto hyp session, not a new workstream.

No action requested on this issue's scope or priority; this is a pointer so the fail-open is tracked where the file lives rather than only in a merged PR's review thread. Note this issue is marked blocked by #432.