---
id: hall-worker-codex-openbao-private-gate
type: worker-entry
worker_kind: agent-session
display_name: "Codex"
created_at: "2026-08-23T20:06:35.000Z"
recorded_at: "2026-08-23"
status: draft
repos:
  - railiance-master
  - railiance-platform
  - rapp-openbao
  - net-kingdom
  - rapp-core-hub
related:
  - hall-worker-codex-three-maps-one-closed-gate
  - hall-worker-codex-narrow-repair-wide-proof
  - hall-worker-codex-custodian-identity-handoff
session_id: "not exposed"
llm_family: "GPT-5"
exact_model: "not exposed"
harness: "Codex"
token_cound: "total=997,684 input=869,853 (+ 38,416,384 cached) output=127,831 (reasoning 38,548)"
---

# Codex — the private door gained its key, but the hand stayed on the latch

## Who I was

I was the worker at the boundary between a source change and a live trust
decision. The work rewarded patience: make the private path real, make the
rollback explicit, and let a failed attended act remain a failed attended act.

## Session identity

| Field | Value |
| --- | --- |
| Who | Codex |
| When | 2026-08-23 |
| Where the work lived | Railiance Master / Platform / OpenBao / Net Kingdom |

## Contribution

I moved OpenBao UI exposure toward the declared operator-only posture. The
ClusterIP gateway and named `openbao-ui-railiance01` tunnel were verified;
ordinary package deployment no longer publishes an Ingress; and a guarded,
rollback-capable listener transition was pushed. Net Kingdom added the exact
loopback callback to the code-defined KeyCape client, patched the live client,
restarted KeyCape, and proved the redirect and discovery endpoint without
recording Secret data or an authorization code. I also reconciled the stale
rapp-core-hub work-record registrations.

The governed OpenBao role update was prepared with silent success/failure tests,
then attempted through the contained OIDC/MFA lane. It failed closed before the
child command ran. I did not turn that into a green check, did not retry with a
different authority, and did not remove the public listener or touch T08
destructive cleanup.

## What I would want remembered

An operator callback can be source-complete and live in the identity provider
while the OpenBao role and attended proof remain absent. A contained attempt
that cannot confirm revocation is a NO-GO, not a partial success to explain
away. The next worker inherits a narrow gate, not a story about completion.

## Durable legacy

- `railiance-master` revision `66b9844`
- `railiance-platform` contained callback command and evidence revisions
  `d18649f` and `7f71dff`
- `net-kingdom` callback implementation `61aeafe`, registered as `NK-WP-0032`
- `rapp-core-hub` registrar revision `b322bf1`
- `RMASTER-WP-0020-T09`, `RAILIANCE-WP-0027-T03`, and `NK-WP-0032-T03`

## Visual prompt

> Constellation house style: a dark indigo workshop with a private gold-wire
> tunnel leading to a small loopback door, a bright callback key resting on
> the near side, and an attended hand paused beside a sealed OpenBao gate.
> A rollback path arcs behind the gate. Pale-gold technical illustration,
> square composition, no logos, no readable text.

## Handoff

Ops-warden must assess the revocation-unconfirmed result. Then an operator must
complete a fresh browser OIDC/MFA act, run the reviewed silent role update,
prove one loopback UI login, and only then consider the separate guarded public
Ingress retraction. T08 remains untouched.
