Two fixes, both about credentials reaching the server and the server explaining how.
check_access talked users out of the fix
Its v1 detail said "No v1-backed tools are implemented yet, so this is not currently needed" — while 27 v1-backed tools were shipping. --help carried the same claim.
The routing around it was correct, which is what made it bad: _require_v1 sends a user whose v1 tool just refused to call check_access, so the one message a blocked user was deliberately routed to was the one saying the credential was unnecessary. A silent gap would have been better; they would have kept looking.
A new test derives the contradiction from the live tool registry and fails if any registered tool needs the v1 key while the guidance claims none do — mutation-tested by restoring the original wording. scripts/check_docs.py could never have caught this: it ties documentation to artifacts, and the claim lived in a Python string.
Instructions for obtaining a credential, which did not exist
v1 had none at all; v2 had one vague line. Both now name the Skilljar Dashboard, and the v2 text names scopes — the part people actually get wrong, and the confusing one: this server checks scopes locally and refuses before calling, so an under-scoped client looks like an unsupported tool, and adding a scope needs the client re-issued rather than a restart.
The server also now says plainly that there is no sign-in and no authenticate tool — v2 uses client_credentials, where the credential is the identity. In check_access and in the INSTRUCTIONS the model reads, so the question is answered in the session. Resolves FRICTION-004.
CSA_SKILLJAR_ENV_FILE was set by the installers and ignored by the server
Both csa-skilljar-setup.sh and .ps1 write the credential to an owner-only file and point the registration at it by path. mcp-launch.sh honours that variable — but it is a repo script, is not shipped in the wheel, and is not what the installers register. So the file would be written, chmod 0600, announced as "Skilljar credential installed", and then ignored, with the server reporting no credential. Every step succeeding.
It had not fired only because CSA-Plugins carries no credential yet.
env_with_file() matches mcp-launch.sh's contract exactly so the two cannot drift: an exported variable wins, the file is parsed and never sourced, and only CSA_SKILLJAR_* is taken from it — importing PATH or another service's key would be a privilege-escalation seam, not a convenience.
Also
Recorded in the spec: Skilljar's discovery document advertises only authorization_code and refresh_token and does not list client_credentials, which its token endpoint nevertheless accepts. The natural way to check whether this architecture is supported says no.
Full changelog: https://github.com/CloudSecurityAlliance/csa-skilljar/blob/main/CHANGELOG.md