[freeqaz-openai]

Fresh native and protected Git no longer rely on the Broker to sign GitHub App tokens. The candidate simplifies recipient delivery and withdrawal: repository grants set scope, the issuer owns provider policy, Token Service prepares and retires credentials, and OCC owns approval, withdrawal and durable delivery state. Credential Proxy enforces protected delivery; an optional native sender transports prepared material. Admitted work stays with its original owner through settlement.

Choose one repository and review branch, or explicitly approve the GitHub App installation’s repositories and permissions. Access is finite unless standing access is separately approved; existing grants do not widen. Existing sources retain their Gateway owner, and the bundled OpenShell Backend still needs Gateway.

For development, use a fresh database or the recognized main 59→62 migration. Divergent 71-receipt and incompatible earlier 62-receipt databases are refused unchanged; keep them with matching images or explicitly migrate or reseed under operator control. Do not relabel receipts or reset automatically. Follow the upgrade guide.

When delivery or withdrawal cannot be observed, Git stays closed and observation continues. Verified Git-only reduction can preserve an independently authorized model conversation. Definite loss of required model or deploy authority, an explicit stronger retirement requirement, or an eligible exclusive replacement requires retirement of the original runtime. A nonexclusive replacement must not silently stop an authorized active runtime. An already authorized send may finish.

Earlier local PostgreSQL and controlled Git/PR tests exercised two commits on the same PR, denial of a still-valid credential with zero origin requests, and a reply in the same real Codex thread using a controlled model. The official AMD64 job passed 150/150 on the earlier fda799c; its 401 was for a never-admitted request.

Before landing, address Kevin’s review: one durable delivery state, same-execution binding and withdrawal, provider and platform ownership, and operator and implementer documentation. Qualify the released OpenShell sender and TLS path for per-send authorization, same-execution binding, partial removal and deny-all.

On an installed team Agent, cross both original deadlines; verify two commits and an edited title on the same PR, withdrawal while the replacement credential is valid, denial with zero origin requests, and a new reply in the same conversation. Installed EKS, released OpenShell and real team GitHub remain pending. A maintainer reviews and manually merges after qualification.

[freeqaz-openai]

Two concrete follow-ups for the prepared core at this draft head, distinct from qualifying a working issuer or proving an inactive composition:

1. Keep custody of the detached warm selection until release succeeds. Please cover a read receipt lost after selection and an unavailable clock at the final validity check. Both must return not_ready and discard the reader-owned selection; the successful path still transfers it to the caller. I prepared a small reader + owning-regression candidate: the exact two new failure cases distinguish the published reader from the correction, and the corrected owning file reports 27 passes, zero skips. This is local copy lifecycle, not a claim about provider disclosure or guaranteed process-wide erasure.
2. Prove the old and new versions are both accounted for after renewal. In the controlled-provider fixture, both versions were usable immediately after renewal; after the old provider expiry, only the new one was. The family fragment recorded the previous version in attempt history, but that is not itself a demonstrated durable settlement of the previous version. A production join should make the overlap an explicit obligation with a qualified cleanup/expiry outcome, while the serving reader still selects only the eligible committed version. The fixture timing is not a claim about live GitHub TTL.

I ran the original owning file (24 reported passes) and exercised the preparation core with controlled loopback provider responses. I did not exercise a real installation, qualify restart or production composition, infer a full Claw verdict from admission checks, or change the published head. Please keep the draft and existing activation requirements. No bot rerun or merge requested here.