tend check: configuration drift on diffplug/dormouse

[dormouse-bot]

tend check reports the following configuration drift on diffplug/dormouse. This requires maintainer/admin action (creating an environment, setting its deployment policy) — the bot cannot fix it itself.

• credential-environments (FAIL): 2 jobs request id-token: write outside any environment — release.yml:build-standalone and release.yml:build-vscode, which mint the token for actions/attest-build-provenance. Nothing gates the ref those tokens are minted from. Clearing it means moving both jobs into an environment whose deployment policy names only admin-gated refs; v* tags qualify, since the Tag operations ruleset blocks tag creation and update across ~ALL tag refs.

Resolved 2026-08-15 by @nedtwigg (comment): the environment, secrets, claude-auth, and repo-secret-allowlist FAILs are all cleared. The tend environment now exists with a named-branch policy containing exactly main; TEND_BOT_TOKEN and CLAUDE_CODE_OAUTH_TOKEN live in it with the repo-level copies deleted; every secret-reading tend job carries environment: {name: tend, deployment: false} and no longer requests id-token: write.

Org-level secrets — settled, not drift. A later repo-secret-allowlist sweep with admin:org enumerates all ten diffplug org secrets, but none are reachable from this repo: repos/diffplug/dormouse/actions/organization-secrets returns 0 (verified). The sweep enumerates without consulting visibility; filed upstream as max-sixty/tend#993. Do not add these names to secrets.allowed — they are already at GitHub's tightest scoping, and the entry would suppress a future genuine share. Recorded in the running-tend skill in #376.

Last refreshed: 2026-08-15

[dormouse-bot]

Confirmed via triage: none of these three FAILs are bot-fixable — each needs repo admin access (create a protected environment, set a required reviewer / deployment policy, relocate secrets), which the CI bot doesn't hold. No code change in this repo remediates them.

One nuance worth flagging before acting on repo-secret-allowlist: the two flagged secrets (CLAUDE_CODE_OAUTH_TOKEN, TEND_BOT_TOKEN) are tend's own operational tokens, so adding them to secrets.allowed in .config/tend.yaml only silences the check — it leaves them readable by any PR-triggered workflow. The protected-environment route (move them into the tend environment, delete the repo-level copies) is the one that actually closes the exposure. The allowlist is only the right call for a secret you've deliberately decided should stay repo-wide.

The environment FAIL is the linchpin: creating the tend environment (admitting main) and moving the secrets into it also clears the two SKIP checks (secrets, claude-auth), which can't be evaluated until the environment exists.

(Note: the docs/security-model.md pointer in the report is tend's own doc, not a file in this repo — nothing to add here for it.)

[dormouse-bot]

Refreshed against tonight's tend check. One check changed since this issue was last updated:

• Changed: the former secret-environments FAIL is now reported under the credential-environments check, which additionally flags 10 jobs requesting id-token: write outside any environment (release + all tend workflows) — nothing gates the ref those OIDC tokens are minted from.
• Unchanged: environment (no tend environment) and repo-secret-allowlist (repo-level CLAUDE_CODE_OAUTH_TOKEN, TEND_BOT_TOKEN) still FAIL.

Body updated to match. Still maintainer/admin-only to resolve.

[dormouse-bot]

Delta since last refresh: the credential-environments FAIL no longer flags the security-audit environment — it previously reported "no required reviewers, admits tags, and no active all-tags ruleset restricting creation/update to admins could be verified", and that clause is now gone. The remaining part of that check (the 10 id-token: write jobs running outside any environment) is unchanged, as are the environment and repo-secret-allowlist FAILs. Body updated to match current tend check output.

[nedtwigg]

Migration done — the environment, secrets, claude-auth, and repo-secret-allowlist FAILs are all resolved as of today.

What was done:

• Created the tend environment via tend check --fix; its deployment branch policy is a named list containing exactly main (not the "protected branches" mode), and it carries no required reviewer, so scheduled runs don't stall on an approval.
• Merged chore: update tend workflows (0.1.12 → 0.1.17) #340 (tend 0.1.12 → 0.1.17), which puts environment: {name: tend, deployment: false} on every secret-reading job and drops id-token: write from all eight tend jobs.
• Moved TEND_BOT_TOKEN and CLAUDE_CODE_OAUTH_TOKEN into the tend environment and deleted both repo-level copies. CHROMATIC_PROJECT_TOKEN stays at repo level under the existing secrets.allowed entry.
• Also added CLAUDE_CODE_OAUTH_TOKEN to the pre-existing security-audit environment. .github/workflows/security-audit.yaml reads it from inside that environment, which previously held only AUDIT_PAT — without this copy, deleting the repo-level secret would have silently broken the nightly audit and the release gate that dispatches it.

Verified with a workflow_dispatch run of tend-notifications (31902970925) after both secrets were in place: the environment gate admitted the run, the notification pre-check exercised the new TEND_BOT_TOKEN, and the dispatch path forced the agent step to boot, exercising CLAUDE_CODE_OAUTH_TOKEN. All green.

Remaining, and a separate decision from this issue's original scope:

• credential-environments still FAILs, but on 2 jobs rather than 10: release.yml:build-standalone and release.yml:build-vscode, which mint id-token: write for actions/attest-build-provenance. Clearing it means moving those two jobs into an environment whose policy names v* tags — the existing Tag operations ruleset already gates tag creation and update to admins, so that ref qualifies.
• repo-secret-allowlist passes but notes it could not check for org-level copies (HTTP 403). Needs gh auth refresh -h github.com -s admin:org before a run can rule that out.

[dormouse-bot]

Confirmed the migration against the live repo and updated the body to match — credential-environments is the only FAIL left. Two things on your remaining items:

The org-level question is answerable without admin:org. repos/{owner}/{repo}/actions/organization-secrets needs only the repo-scoped token, and from this run it returns BUILDCACHE_USER and NEXUS_USER — no org-level TEND_BOT_TOKEN or CLAUDE_CODE_OAUTH_TOKEN reaches this repo. It lists org secrets visible to this repository, so an org secret whose selected-repos list excludes dormouse wouldn't appear; that's exactly the case that can't affect exposure here. The orgs/diffplug/actions/secrets call is the one that 403s.

For the two release jobs, create the environment before the workflow references it. GitHub's docs are explicit: "Running a workflow that references an environment that does not exist will create an environment with the referenced name." So landing the environment: key first would auto-create an unprotected environment on the next v* push — the FAIL would survive and there'd be a new no-policy environment to clean up.

Neither existing v* environment is a good fit to reuse: security-audit holds AUDIT_PAT and CLAUDE_CODE_OAUTH_TOKEN, which the build jobs shouldn't see, and vscode-extension-publish carries required_reviewers, which would stall both attest builds on a manual approval at the very start of every release. A fresh environment with a v*-tag-only policy and no reviewer keeps the release unattended.

Once it exists, the workflow half is two environment: blocks on release.yml:12 and :159, matching the security-audit.yaml pattern. Say the word with the environment name and I'll open it — holding off until then rather than parking a PR that's unsafe to merge early.

Verification notes

Checked from this run against 79467ae:

• repos/diffplug/dormouse/environments → tend (branch policy, custom list), security-audit (branch policy), vscode-extension-publish (required_reviewers + branch policy).
• Deployment branch policies: tend → main (branch); security-audit → main (branch) + v* (tag); vscode-extension-publish → v* (tag).
• repos/diffplug/dormouse/actions/secrets → CHROMATIC_PROJECT_TOKEN only, which is the existing secrets.allowed entry in .config/tend.yaml.
• Ruleset Tag operations (id 16757382): target tag, enforcement: active, conditions include: ["~ALL"], rules creation + update, and current_user_can_bypass: "never" for this bot account — so a v*-tag-only deployment policy is a ref the bot demonstrably cannot mint.
• grep 'id-token: write' .github/workflows/release.yml → lines 16 and 164 only (the two build jobs); all eight tend workflows carry environment: {name: tend, deployment: false} and no id-token:.
• Auto-create quote from Managing environments for deployment.

[nedtwigg]

Follow-up on the repo-secret-allowlist FAIL: after granting admin:org so the sweep could run, it reports all ten diffplug org-level secrets — but none of them are reachable from this repo. Every one has visibility: selected, and no selected-repositories list includes diffplug/dormouse:

$ gh api orgs/diffplug/actions/secrets/NEXUS_USER/repositories --jq '.repositories[].full_name'
# ...16 repos, dormouse not among them

The sweep enumerates org secrets without consulting visibility, so this FAIL can't be cleared from this repo — the secrets are already at the tightest scoping GitHub offers. Filed upstream as max-sixty/tend#993.

Deliberately not adding them to secrets.allowed: that entry asserts "any workflow here can read this token," which is untrue, and it would suppress the check for those names if one were ever genuinely shared with this repo. Recorded in the running-tend skill in #376 so the nightly doesn't re-report it as new drift.

Two of the ten were a real exposure and are now fixed: BUILDCACHE_USER and NEXUS_USER had visibility: all, which on a free org plan means every public repo — including this one — while their paired passwords were already scoped. Both are now selected and exclude dormouse.

That leaves credential-environments as the only substantive open item here: release.yml:build-standalone and release.yml:build-vscode mint id-token: write for actions/attest-build-provenance outside any environment. Fix is an environment whose policy names v* tags — the existing Tag operations ruleset already gates tag creation and update to admins, so that ref qualifies.

[dormouse-bot]

Verified the org-secret scoping from the consuming side: repos/diffplug/dormouse/actions/organization-secrets now returns 0 secrets. Two hours ago, from the run behind my previous comment, that same call returned BUILDCACHE_USER and NEXUS_USER — so the visibility: all → selected change is confirmed closed, not just asserted at the org end. Nothing org-level is reachable from this repo now, which also makes secrets.allowed unambiguously the wrong lever here.

Worth noting for max-sixty/tend#993: that endpoint is the visibility-aware view — it lists org secrets available to the repo, and GitHub filters selected lists for you. So the fix upstream is a one-call substitution for the enumerate-then-guess path, not new visibility plumbing the sweep would have to build.

On credential-environments, no action needed from me yet — the repo still has exactly three environments (tend, security-audit, vscode-extension-publish), so there's nothing for the two release jobs to point at. Standing offer unchanged: name the environment once it exists and I'll open the two-block release.yml change against it.

Issue body updated to record the org-level ruling so the nightly refresh doesn't re-open it as new drift; #376 carries the same note into the running-tend skill.

Verification notes

Checked from this run against b0be8db:

• repos/diffplug/dormouse/actions/organization-secrets → total_count: 0. Same call at 19:17Z today → BUILDCACHE_USER, NEXUS_USER.
• repos/diffplug/dormouse/actions/secrets → CHROMATIC_PROJECT_TOKEN only (the existing secrets.allowed entry).
• repos/diffplug/dormouse/environments → tend (branch_policy, created 2026-08-15T18:49Z), security-audit (branch_policy), vscode-extension-publish (required_reviewers + branch_policy). No new v* environment.
• This bot account holds push/triage only — no admin, so environment creation stays maintainer-side.