path-token mint rejects /github/repos/** as invalid_paths (accepts /github/** and /github/repos/*)

[kjgbot]

Summary

The workspace path-token mint (POST → RelayAuth "direct workspace path-token mint") rejects /github/repos/** as invalid_paths, while accepting /github/**, /github/repos/*, and /github/repos/<owner>/**. Because callers mint all their scopes in a single request, this one path fails the entire batch, which took down the Factory relayfile mount (it received no fs token and 403'd on every read with missing required scope: fs:read).

Reproduction (against production agentrelay.com/cloud, 2026-07-24)

Minting one path at a time through the delegated-token exchange:

Requested read path	Result
relayfile:fs:read:/github/repos/**	❌ 400 {"error":"paths must contain valid relayfile paths","code":"invalid_paths"}
relayfile:fs:read:/github/**	✅ OK → /github/**
relayfile:fs:read:/github/repos/*	✅ OK → /github/repos/*
relayfile:fs:read:/github/repos/AgentWorkforce/**	✅ OK
relayfile:fs:read:/github/repos/*/**	❌ invalid_paths
relayfile:fs:read:/linear/issues/**, /slack/channels/**, /factory/observability/**, etc.	✅ OK

So the rejection is specific to a ** wildcard at the second segment under a provider (/github/repos/**) — ** at the provider root (/github/**) or below a literal owner (/github/repos/<owner>/**) is fine.

Why this is a bug

/github/repos/** is a natural, well-formed subtree glob and was in active use (Factory's FACTORY_RELAYFILE_SCOPES requested it, and it worked until ~2026-06-19 when a previously-minted token expired). Rejecting it is inconsistent with accepting both its parent (/github/**) and its children (/github/repos/<owner>/**).

Note on the code

In this repo's current checkout, normalizePathTokenPath (packages/server/src/routes/tokens.ts:1707) would accept /github/repos/** — it collapses a trailing /** to /* (line 1726-1727), yielding /github/repos/*, which is exactly the shape that mints successfully on its own. So the deployed validator that returns invalid_paths for /github/repos/** differs from this checkout, or there is an additional provider-tree/depth check not in this file. Please reconcile against the deployed version.

Impact

Any caller batching an unlucky path shape gets an opaque, total mint failure (invalid_paths) with no indication of which path was rejected — see the companion cloud issue about the delegated-token endpoint failing the whole batch.

Suggested fix

Accept /github/repos/** consistently (it's a valid subtree glob), or document the exact path grammar the mint enforces and return an error that names the offending path.