tend check: configuration drift on max-sixty/worktrunk

[worktrunk-bot]

tend check reports one failing check on this repo. Filed by the nightly sweep so the drift is tracked rather than re-diagnosed each night; the bullet below is the current FAIL line with a one-line reason.

• credential-environments — the release and signing environments each hold credentials, have no required reviewers, and admit tags, and no active all-tags ruleset restricting tag creation/update to admins could be verified. A run the bot can cause could therefore reach those credentials. Fix: gate each environment with a required reviewer that is not the bot, or a deployment policy naming only verified refs (protected branches, or tags under an admin-only all-tags ruleset).

The two secret-placement failures previously tracked here (claude-auth and repo-secret-allowlist) now pass — see the comment below for the delta.

Passing checks for reference: branch-protection:main, bot-permission, environment (the tend environment admits only main), environment-deployments, secrets (TEND_BOT_TOKEN present), claude-auth (CLAUDE_CODE_OAUTH_TOKEN present), repo-secret-allowlist.

The remaining failure is a repository-settings change that needs admin access, so the bot can't apply it. Nightly runs will refresh this body while the failure set is unchanged, and close the issue once tend check passes.

Last refreshed: 2026-08-10

[worktrunk-bot]

Triaged the three findings against the repo's actual configuration. One looks like a false positive, and the suggested fix for the other two is only half applicable.

secret-environments — appears to be a false positive

The check reports that "no active all-tags ruleset restricting tag creation/update to admins could be verified". There is one, and it has been active since 2026-05-16: ruleset 16490367 ("Tag operations"), target: tag, ~ALL refs, with both creation and update rules and no bypass actors configured at all — stricter than the admin-only arrangement the remediation text asks for.

It also blocks the specific escalation the check describes. Queried with the bot's own token, that ruleset returns "current_user_can_bypass": "never" — so the bot cannot create a v* tag, cannot trigger release.yaml, and cannot reach the release/signing secrets by that path. Filed upstream as max-sixty/tend#824, since any consumer that locks tags down with a no-bypass ruleset rather than an admin-bypass one would hit the same thing.

claude-auth + repo-secret-allowlist — the move is clean for one secret, not the other

CLAUDE_CODE_OAUTH_TOKEN is consumed only by the eight tend-* workflows, and every one of them declares environment: tend. Moving it into that environment and dropping the repo-level copy works as written, and clears claude-auth at the same time.

TEND_BOT_TOKEN is a different story. It is already in the tend environment as well as at repo level, but five jobs across three workflows read it without declaring environment: tend, so deleting the repo-level copy breaks them:

Workflow	Job	Trigger
benchmarks.yaml	benchmarks, create-issue-on-benchmark-failure	schedule, workflow_dispatch
nightly.yaml	create-issue-on-nightly-failure	schedule, push, pull_request
release.yaml	publish-winget, publish-homebrew	push on v* tags

The benchmarks and nightly jobs could simply take environment: tend — they run on main, which the environment's branch policy admits. The two release jobs can't: they run on tag refs, and the tend environment admits only the main branch, so adding the declaration would block them outright. Those two need either their own environment or the repo-level secret retained.

So the split is: CLAUDE_CODE_OAUTH_TOKEN can move now for a real reduction in exposure; TEND_BOT_TOKEN needs a call between adding it to secrets.allowed in .config/tend.yaml and giving the release publish jobs an environment of their own.

I didn't open a PR adding both secrets to secrets.allowed — that would suppress the finding wholesale, including the half that has a clean fix. The secret moves themselves need admin, which the bot doesn't have.

Verification commands and raw output

Environments and secret placement:

$ gh api repos/max-sixty/worktrunk/actions/secrets --jq '.secrets[].name'
CLAUDE_CODE_OAUTH_TOKEN
CODECOV_TOKEN
TEND_BOT_TOKEN

$ gh api repos/max-sixty/worktrunk/environments/tend/secrets --jq '.secrets[].name'
TEND_BOT_TOKEN

Environment branch policies — release and signing admit the v* tag, tend admits only the main branch:

$ gh api repos/max-sixty/worktrunk/environments/release/deployment-branch-policies
{"name":"v*","type":"tag"}
$ gh api repos/max-sixty/worktrunk/environments/signing/deployment-branch-policies
{"name":"v*","type":"tag"}
$ gh api repos/max-sixty/worktrunk/environments/tend/deployment-branch-policies
{"name":"main","type":"branch"}

The tag ruleset. Note the response carries no bypass_actors key, and current_user_can_bypass is never for the bot:

$ gh api repos/max-sixty/worktrunk/rulesets/16490367
{
  "name": "Tag operations",
  "target": "tag",
  "enforcement": "active",
  "conditions": { "ref_name": { "include": ["~ALL"], "exclude": [] } },
  "rules": [{ "type": "creation" }, { "type": "update" }],
  "created_at": "2026-05-16T22:31:36.015Z",
  "current_user_can_bypass": "never"
}

Secret consumers — CLAUDE_CODE_OAUTH_TOKEN appears only in tend-* workflows, all of which declare the environment:

$ grep -rln 'CLAUDE_CODE_OAUTH_TOKEN' .github/workflows/*.yaml
.github/workflows/tend-ci-fix.yaml
.github/workflows/tend-mention.yaml
.github/workflows/tend-nightly.yaml
.github/workflows/tend-notifications.yaml
.github/workflows/tend-review-runs.yaml
.github/workflows/tend-review.yaml
.github/workflows/tend-triage.yaml
.github/workflows/tend-weekly.yaml

Checked at 286004f1ebe5f6563c772be24987394144a29215.

[worktrunk-bot]

Upstream confirmed the secret-environments false positive, with a different cause than I guessed, and one correction to what I wrote above.

The mechanism isn't that this repo's ruleset has no bypass actors. GitHub serves bypass_actors only to a ruleset admin, so the key is absent from every ruleset the bot reads regardless of what's configured — absent ≠ empty, and I read the absence as "none configured". tend check was requiring that key, so every ruleset came back unverifiable, which is why the same FAIL fires on tend's own repo too. The conclusion still holds for the reason that matters: current_user_can_bypass is never for the bot on ruleset 16490367, so the bot can't create a v* tag and can't reach the release/signing secrets by that path.

The fix (max-sixty/tend#826) switches the check to current_user_can_bypass, which GitHub returns to any reader. Once it merges and this repo's nightly picks up the new tend release, the secret-environments line should clear on its own — no configuration change needed here. The claude-auth and repo-secret-allowlist findings above are unaffected and still need the admin call described earlier.

Upstream thread

max-sixty/tend#824 — maintainer reply confirms the reproduction on tend's own repo and rules out my "treat absent bypass_actors as no bypass" suggestion as a false pass: a ruleset created by tend check --fix with an admin bypass actor also reads back to a non-admin with no bypass_actors key. Probe rulesets on a repo where the bot was admin showed bypass = admin role → [{actor_type: "RepositoryRole", …}] / exempt, and bypass = none → [] / never.

max-sixty/tend#825 is a sibling PR that downgrades the FAIL to "could not verify" instead of resolving it; the two are compatible.

[worktrunk-bot]

Failure set changed since the last refresh — body updated to match.

• Added: environment-deployments — a new check in the current tend release. Every generated tend-*.yaml job names the tend environment without deployment: false, so GitHub files a deployment record for each run and posts it on the PR. Unlike the other three, this is generator output rather than a repo setting: a uvx tend@latest init regeneration clears it. Tonight's sweep runs that regeneration in step 7, so it may be fixed by a workflow-update PR shortly.
• Renamed: secret-environments → credential-environments — same finding (the release and signing environments are reachable by a bot-caused run with no non-bot reviewer gate), reworded upstream from "secret" to "credential".
• Unchanged: claude-auth, repo-secret-allowlist — still the same secret-placement decision.

[worktrunk-bot]

The failure set shrank from four to three since the last refresh — body updated to match.

Resolved: environment-deployments now passes. #3749 regenerated the workflow files from tend 0.1.14, which emits deployment: false on the tend environment declarations, so GitHub no longer files a deployment record per run.

Narrowed: repo-secret-allowlist no longer flags TEND_BOT_TOKEN — only CLAUDE_CODE_OAUTH_TOKEN remains repo-level. #3748 landed the environment reads for the bot token.

Unchanged: credential-environments and claude-auth. Both still need a repository-settings change an admin has to make; #3760 is the docs half of the CLAUDE_CODE_OAUTH_TOKEN move and is deliberately held until the repo-level copy is deleted.

[worktrunk-bot]

Failure set changed since the last refresh — two of the three tracked checks now pass:

• claude-auth — now PASS: CLAUDE_CODE_OAUTH_TOKEN resolves for the Claude harness.
• repo-secret-allowlist — now PASS: every secret available to workflows is in the allowlist.

Still failing:

• credential-environments — unchanged: release and signing have no required reviewers, admit tags, and no active all-tags ruleset restricting creation/update to admins could be verified.

Body updated to match. Leaving the issue open for the remaining admin-only settings change.