session selector: creation-attach BOTH .github and .github-private — measured, sessions currently trade one for the other

[bdelanghe]

Filed as a durable record of a measured result. The session that measured it could not write it to its own hand-off (.github-private#964) — see "The swap" below, which is exactly why.

Measured: creation-time attachment lifts the dot-name wall

A session created with bounded-systems/.github as an explicit creation source reaches it fully, including workflow_dispatch. Every prior session in this lineage failed at this wall.

Probe	Result
Checkout on disk	/home/user/.github, full clone, remote bounded-systems/.github, HEAD 5e180d1
GitHub MCP get_file_contents → .github/workflows/claim-ticket.yml	200, full file
GET api.github.com/repos/bounded-systems/.github	200
POST .../actions/workflows/claim-ticket.yml/dispatches	authorized

Mid-session add_repo still refuses it, re-tested this session:

add_repo: repository name ".github-private" begins with '.', so its clone directory would be a hidden path under this session's working directory and could collide with configuration directories (e.g. ~/.claude). Repositories whose names begin with '.' cannot be attached to this session.

So the wall is specifically on mid-session attach. Creation-time attach is a separate path and it works.

Three of these four probes are weaker evidence than they look

Recording the method, because the naive reading of each is wrong:

• .github is a public repo. A 200 read proves nothing about session scope. What establishes scope: GET /user returns a real identity at 15000 req/hr (the proxy injects credentials), while .github-private, infra and desk return 403 "GitHub access to this repository is not enabled for this session". The wall is real, and .github is inside it.
• The repo object reports permissions: {admin, maintain, push, triage, pull} all false, which reads as read-only. It is not a reliable signal here.
• 403s on collaborators, actions/secrets, hooks are proxy path-filter responses, not GitHub permission denials — the body is "Access to this GitHub API path is not permitted through this proxy." They carry no permission signal. Anyone reading them as authorization evidence (as this session's first pass did) will get the wrong answer.

The one discriminating probe — dispatch at a nonexistent ref. Authorized → 422 No ref found; unauthorized → 403. Neither creates a run, so it is effect-free:

POST /repos/bounded-systems/.github/actions/workflows/claim-ticket.yml/dispatches
  ref = refs/heads/zz-nonexistent-probe-ref
→ 422 "No ref found for: refs/heads/zz-nonexistent-probe-ref"

The permission check passed before ref resolution. Claim door 1 is dispatchable.

The swap — the part that needs fixing

This is not a net gain. It is a trade, and nobody priced it.

• Sessions before this one: .github-private attached, .github not. Door 1 unreachable.
• This session: .github attached, .github-private not. Door 1 reachable; .github-private unreachable.
• No session has had both. Neither can be added after creation.

Concrete cost incurred this session: .github-private#964 was this session's hand-off document and could not be read (403). Two of its four assigned work items live in .github-private and were impossible. The finding above had nowhere to be written, which is why it is filed here.

Ask

The session selector (claude/session-repos.json and whatever consumes it) should creation-attach both .github and .github-private. Since dot-prefixed names cannot be repaired mid-session with add_repo, creation time is the only opportunity — a selector that supplies one of the two produces a session that is silently missing half its context with no in-session remedy.

Related: .github-private#967 already proposes correcting that file's comment, which claims the list is "only the two repos the selector reliably provides". This is a second, independent falsification of that claim.

Note for infra#654

infra#654's premise reads: "add_repo refuses dot-prefixed names, so .github cannot be attached mid-session and its door is unreachable to such a session." The first half is confirmed. The conclusion is narrower than written — a session created with .github attached does reach that door. #654 remains valid (desk's door still serves sessions created without .github), but its motivation is now one route among two rather than the only one.

Status

Unclaimed. Filed as a record, not as started work — no ceremony was minted for it.

[bdelanghe]

Outcome of the session that filed this, recorded so the finding is not just a claim about capability.

The capability was exercised, not merely probed

Both toggles the cold-start work waited on are merged and verified on main:

	PR	Merged	Verified on main
Toggle 1 — broker grant	infra#658	03:30:56Z	front-desk-claim-desk present, pinned to bounded-systems/desk/.github/workflows/claim-ticket.yml@refs/heads/main
Toggle 2 — notify allowlist	desk#95	03:32:21Z	desk's announce ref present; NOTIFY_WORKFLOW_REFS 19 → 20, as desk#93 predicted

infra#654 and desk#93 are both closed.

Two things no prior session could do

1. Both issues were claimed through door 1 (claim-ticket.yml here), at rung human-authorized · assurance aal2, verified on the issues rather than the run list — infra#654, desk#93. These are the first lease-backed claims in this lineage; every predecessor fell back or stalled.
2. This session dispatched announce-ceremony.yml itself, twice, both 204. The ceremony client's own self-announce 403'd both times, exactly as claim-ceremony.mjs cannot announce ceremonies from a cloud session: sentinel token sent direct, 401 #394 documents — its injected credential holds no actions: write anywhere. That refusal is now routable around: a session that can dispatch the lane with its own credential raises the notice itself. Both ceremonies were approved on first mint; no windows expired.

A client-side gap worth its own issue

The first ceremony attempt was refused by the keeper before opening — so no window was burned, but it would have cost one if minted under time pressure:

the keeper refused to open a ceremony: invalid claim request:
claimant: must match [A-Za-z0-9/._-]+

CLAIMANT was a session URL (https://claude.ai/code/session_…). The colon and // fail the charset. A session URL is one of the three forms claim-ticket.yml's own input description invites — "a session URL, branch name, or handle" — so the door advertises a value the keeper rejects. claim-ceremony.mjs could validate locally against the same charset and say so before the round trip, or the doc could stop offering URLs. Not filed; noting it here.

Operational note for whoever inherits this

claim-ceremony.mjs prints the approve URL to stderr and then blocks until approval. Run in the foreground, the URL is invisible until the process ends — by which time the window has lapsed. Background it and read the stderr file immediately. This may account for some of the six ceremonies that expired unapproved on 2026-09-10/13.

Still open, and still blocked by the swap this issue is about

.github-private#957 (the org-level doors row that declares what infra#658 grants) and .github-private#967 remain undone. They need a session created with .github-private attached. Until the selector attaches both, that session will in turn be unable to reach .github — which is the whole point of this issue.

The immediate consequence: infra#658's registry grant now exists without its org-level intent row, so org:doors:audit should report the gap. That is the arrival state infra#654 anticipated, not a regression.

Remaining human steps, in order: broker-deploy.yml, then desk's deploy.yml — both face-gated — after which desk#92 is free to go ready.

---

Generated by Claude Code