[infra] Migrate smartwatermelon/ repos to a new GitHub org for org-level secret management

[twistedmelonman]

Summary

Create a new GitHub organization for repos currently under smartwatermelon/ (personal account). This eliminates per-repo OAuth token management by enabling org-level secrets, reducing annual claude setup-token minting from ~30 invocations to 2 (one per org).

Background

Claude Code Action CI across ~30 repos requires CLAUDE_CODE_OAUTH_TOKEN secrets minted via claude setup-token. Personal GitHub accounts cannot set organization-level secrets — each repo needs its own copy. GitHub orgs (even free-tier) support org-level secrets shared across all repos.

Investigated alternatives that turned out to be dead ends:

• grll/claude-code-login (automated PKCE OAuth flow): Anthropic's token endpoint returns 429 for third-party callers. Confirmed locally and in GHA. Fork at smartwatermelon/claude-code-login can be deleted.
• Workload Identity Federation: eliminates token minting entirely but switches CI billing from Max subscription (flat rate) to per-token API rates. Non-starter.
• Anthropic token list/revoke API: undocumented endpoint is broken (capped at 1000, ignores pagination). Feature requests (#22995, #48373, #59378) all closed or unresolved.

Plan

Phase 1: Create the new org

1. Create a new free-tier GitHub organization (name TBD)
2. Verify free-tier features are sufficient: all repos are public, so protected branches, code owners, environment secrets, etc. are all available on Free

Phase 2: Transfer repos

1. Inventory all repos under smartwatermelon/ that use Claude Code Action CI
2. Transfer repos to the new org via GitHub UI (Settings → Transfer)
   • GitHub maintains redirects from old URLs
   • Note: Transferring repos changes the remote URL. Each local clone needs git remote set-url origin updated
3. Script the remote URL update across all local clones:

   # For each repo in ~/Developer/
   cd ~/Developer/<repo>
   git remote set-url origin git@github.com:<new-org>/<repo>.git

Phase 3: Update cross-references

1. Update CLAUDE.md files that reference smartwatermelon/ repo paths
2. Update claude-wrapper if it has org-specific routing logic
3. Update any hardcoded repo references in CI workflows (e.g., actions/checkout with explicit repo paths)
4. Update blog posts at projectinsomnia.com that reference smartwatermelon/ GitHub URLs (GitHub redirects will work but canonical URLs are better)
5. Update the dotfiles repo if it contains org-specific configuration

Phase 4: Set up org-level secrets

1. Mint one token via claude setup-token
2. Set as org-level secret:

   gh secret set CLAUDE_CODE_OAUTH_TOKEN --org <new-org> --visibility all

3. Remove per-repo CLAUDE_CODE_OAUTH_TOKEN secrets from transferred repos (they'd shadow the org secret)
4. Verify CI passes on a representative repo

Phase 5: Do the same for nightowlstudiollc (if not already done)

1. NOS already has org-level secrets capability (Team plan, staying at $4/month)
2. Mint one token, set as org-level secret
3. Remove per-repo secrets
4. Verify CI

Phase 6: Cleanup

1. Delete the smartwatermelon/claude-code-login fork (dead end, confirmed blocked by Anthropic 429)
2. Create a token tracking doc (CSV or markdown table in dev-env) recording:
   • Org name
   • Token minted date
   • Token expiry date
   • Which setup-token invocation produced it
3. Set a calendar reminder for annual rotation (~2 weeks before expiry)

Outcome

Before	After
~30 setup-token mints/year	2 mints/year
Per-repo gh secret set loop	2 org-level gh secret set calls
No audit trail	Token tracking doc
Personal account (no org secrets)	Free org (org-level secrets)
nightowlstudiollc: $4/month (Team)	nightowlstudiollc: $4/month (unchanged)

Open questions

• Org name for the new smartwatermelon org
• Whether any smartwatermelon/ repos have repo-level secrets beyond CLAUDE_CODE_OAUTH_TOKEN that would need migration
• Whether any CI workflows reference smartwatermelon/ in hardcoded paths (beyond what GitHub redirects cover)
• Confirm nightowlstudiollc is already using org-level secrets or needs the same Phase 4 treatment

[twistedmelonman]

Findings from the per-repo-token investigation (superseded by this issue)

I'd been working a parallel plan for per-repo tokens before this issue landed. That approach is dead — this one is strictly better — but the investigation produced findings that bear on Phase 2/3 and three of the four open questions. Posting them so they're not re-derived.

⚠️ Highest-risk item: github-workflows is a cross-org dependency

Every Claude-consuming repo in both orgs hardcodes uses: smartwatermelon/github-workflows/.... Verified today across the fleet — 15 smartwatermelon repos, and spot-checked nightowlstudiollc/{networth-agent,kebab-tax,night-owl-studio}, all pinned to @v3.1.0.

This means transferring github-workflows doesn't just affect the repos moving with it — it affects nightowlstudiollc repos that aren't part of this migration at all.

GitHub redirects do cover uses: refs, so CI shouldn't hard-break on transfer. But two consequences worth planning around:

1. Dependabot will not follow the redirect cleanly. dependabot.yml in these repos explicitly targets smartwatermelon/github-workflows (it's named in the config comments). Post-transfer, expect either silent staleness or a wave of confused PRs across ~30 repos. Related: we already know fetch-metadata@v2 mislabels reusable-workflow majors as patch.
2. Suggested sequencing: transfer github-workflows first, alone, verify one consumer repo's CI in each org, then update all uses: refs fleet-wide, and only then transfer the remaining repos. Treating it as "just another repo in the batch" is where this bites.

A cheaper alternative worth considering: leave github-workflows in smartwatermelon/ permanently. It holds no secrets and needs no org-level secret — only the consumers do. That sidesteps the whole class of problem, at the cost of a split-brain org layout.

Open question: "any repo-level secrets beyond CLAUDE_CODE_OAUTH_TOKEN?"

Answered — exactly one. Full audit of all secret names across all smartwatermelon repos:

• smartwatermelon/ralph-burndown: KEBAB_TAX_GITHUB_TOKEN — and this repo is archived, so it likely needs no migration at all, just a decision.

Every other repo with any secret has only CLAUDE_CODE_OAUTH_TOKEN. Nothing else to migrate.

Open question: "confirm nightowlstudiollc is already using org-level secrets"

Answered — yes, org-level, scoped to All repositories (confirmed via org settings UI).

But there's a wrinkle for Phase 5: two repos also carry redundant repo-level secrets that shadow the org secret — networth-agent and photo-game-poc. Phase 5 step 3 should target specifically these two. Note photo-game-poc is archived.

Also relevant to Phase 5 scoping: 11 non-archived NOS repos actually consume the org secret (all have claude-blocking-review.yml/claude.yml), not just the 2 with repo-level overrides. The "All repositories" scope made the other 9 invisible to a gh secret list scan.

Archived-repo detection — a trap I fell into

When identifying archived repos, use gh repo view --json isArchived, not CI-run recency. I initially inferred from gh run list and got it wrong for Auramaur and tilsit-caddy — both showed activity within ~90 days despite being genuinely archived, because archiving doesn't gate or erase workflow run history.

Confirmed archived, holding a CLAUDE_CODE_OAUTH_TOKEN (candidates to skip entirely in Phase 2):

smartwatermelon/: Auramaur, pre-commit-testing, transmission-filebot, tilsit-caddy, lock-sync-old, smartwatermelon.github.io
nightowlstudiollc/: photo-game-poc

Worth deciding explicitly whether archived repos transfer at all — they can't run CI, so they don't need the org secret.

Corroborating the dead ends

Independent confirmation of two items already listed:

• Anthropic token list/revoke API: the undocumented GET /api/oauth/organizations/{org}/oauth_tokens returns exactly 1000 results, all is_revoked: false, created_at stale by 3+ months, and silently ignores limit/order params (retried and confirmed). No field distinguishes a CI token from a session token — application_name is "Claude Code" for all of them. Not usable for auditing.
• anthropics/claude-code#22995 ("Token/Session Management Dashboard" — device list, creation dates, per-device revoke) was closed as not planned. Worth adding to the dead-ends list: it's the clearest signal no official tooling is coming.
• On rotation reliability: anthropics/claude-code#43801 reports revocation taking days to propagate server-side, and claude-monitor's revoke script retries up to 10 rounds. Don't treat revocation as an instant kill switch in the Phase 6 rotation runbook.

Phase 6 note

For the token tracking doc — I'd tested 1Password as the store and confirmed the mechanics work, in case it beats a CSV: the service account can't op item create (permission-blocked, returns error 101), but op item edit and op item get both work and support typed DATE fields. One quirk: op item get --format json returns DATE fields as Unix epoch seconds, not ISO strings. With only 2 tokens to track post-migration, a markdown table is probably sufficient — but the 1Password path exists if you want expiry queryable by script.

[twistedmelonman]

Outcome

Done, 2026-09-04 — but not as designed, and with a permanent shortfall worth reading before anyone builds on it.

What was executed. Not the six-phase transfer this issue sketched. The migration ran as a rename-then-reclaim: the personal account smartwatermelon was renamed to twistedmelonman, then smartwatermelon was re-created as an organization and repos were transferred into it.

25 of 30 repos moved. Five never will.

dotfiles, claude-config, personify, huddle-transcribe, projectinsomnia are permanently blocked by GitHub's popular repository namespace retirement. A path OWNER/REPO is retired forever when the repo saw >100 clones or >100 Actions runs in the week before a rename, or shipped a Marketplace action. It is an anti-repo-jacking measure, and it binds the string, not the account — so the new smartwatermelon org inherited the old user account's retired paths. It blocks transfer (HTTP 422) and creation alike. A support ticket is in flight; assume it will not be granted.

The trap that cost the most time. GitHub Actions does not follow owner redirects when resolving a reusable-workflow reference — the literal owner/repo must exist. The REST API does follow them. So every gh api check reported healthy while CI died at 0s with no jobs and no logs. If a workflow goes silent after a rename, check the literal path before checking anything else.

Two more findings in the same family, both now documented:

• GitHub App installations do not follow repo transfers. anthropics/claude-code-action@v1 is a downloaded Action; the Claude GitHub App (github.com/apps/claude) is a separate, account-level install. The action cannot install the app — only an account owner can.
• Org-level secrets do not reach private repos on GitHub Free. Both orgs currently read plan=team, but that plan was bought to file a support ticket and will be dropped. Every private repo running a Claude workflow keeps its own repo-level copy. See docs/token-rotation.md.

The stated benefit did not fully land

This issue's motivating benefit was org-level secret management plus branch protection on the three private repos that returned 403. Measured after the migration:

	before	after
smartwatermelon/scripts	403 cannot be set	404 not set
smartwatermelon/claude-config-backup	403 cannot be set	404 not set
nightowlstudiollc/cleanroom	403 cannot be set	protected

The migration removed the blocker; it did not apply protection. cleanroom is covered only because nightowlstudiollc carries a "Claude blocking review" org ruleset. The new smartwatermelon org has no rulesets at all, so all 25 transferred repos are protectable and unprotected.

That is new, previously unowned work: W0 — create the smartwatermelon org ruleset, now at the head of the fleet critical path (W0 → W1 → W2 → W3). Filed in the backlog design.

F4, closed alongside

F4 turned out not to need the token router. The distinction that made it cheap: GH_TOKEN was never the wrong identity, only a too-narrow scope on the right one. The fix is a hint in gh-wrapper.sh that detects GitHub's own needs the "admin:org" scope on stderr and prints the env -u GH_TOKEN re-run.

Documentation

• docs/superpowers/specs/2026-09-03-org-migration-design.md — design and runbook
• docs/superpowers/specs/2026-09-01-infrastructure-backlog-design.md — I3/F4 marked done, the private-repo-protection benefit struck on measurement, W0 added (docs(backlog): record the I3/F4 outcome and the protection gap it left #88)
• docs/token-rotation.md — where each CLAUDE_CODE_OAUTH_TOKEN copy lives, and the one-token/one-expiry reality (docs(token-rotation): one token in five places, expiring 2027-06-29 #87)
• scripts/org-migration/ — snapshot/transfer/verify tooling with a hermetic stub-gh suite

Still open, tracked elsewhere

• Runbook Part D on TILSIT and MIMOLETTE; the gh wrapper's temporary twistedmelonman=smartwatermelon login alias comes out after that.
• Support ticket on the five retired paths.
• Splitting and rotating the shared token — deliberately deferred.
• [infra] Make smartwatermelon/scripts public: secret audit, history rewrite, branch protection #85 (scripts goes public), org-migration: three conditions the design's failure table does not cover #84 (three spec gaps).

Closing.

[twistedmelonman]

Migration complete. Outcome and the protection shortfall are in the comment above; the doc changes landed in #88. Follow-on work is tracked as W0 (create the smartwatermelon org ruleset) in the infrastructure backlog design.

[twistedmelonman]

Correction to the outcome comment above, 2026-09-05.

That comment stated cleanroom is protected "only because nightowlstudiollc carries a Claude blocking review org ruleset," and that the 25 transferred repos were left unprotected. Both halves were wrong.

The ruleset is enforcement: disabled and enforces nothing:

$ gh api orgs/nightowlstudiollc/rulesets --jq '.[] | "\(.name)\t\(.enforcement)"'
Claude blocking review    disabled

$ gh api repos/nightowlstudiollc/cleanroom/rules/branches/main
[]

Every protected repo in both orgs is protected by classic per-repo branch protection. The ruleset was credited on its name without reading its enforcement field.

The 25 transferred repos were also not unprotected — most carried claude-review / run-review through the transfer intact. The real gap was 9 repos, closed 2026-09-05 by applying the dotfiles/claude-config exemplar per-repo. 33 of 37 non-archived repos now enforce the review check, up from 25.

Four repos remain, tracked in #89: they have no review workflow, so protecting them would report "protected" while enforcing nothing. Org rulesets as the scaling mechanism are evaluated in #90. The design doc corrections landed in #91.

The migration outcome itself — 25 of 30 repos moved, five paths permanently retired, the Actions-redirect trap — is unchanged.