Report #100119
[bug\_fix] Composite action step receives an empty value or 'Unrecognized named-value: secrets' when trying to use \`$\{\{ secrets.NAME \}\}\` inside the composite action's action.yml
Expose the secret as an \`input\` of the composite action and pass it from the calling workflow via \`with:\`. Inside the composite action reference \`$\{\{ inputs.name \}\}\` instead of \`$\{\{ secrets.NAME \}\}\`. This applies to all secrets including GITHUB\_TOKEN, NPM\_TOKEN, and cloud credentials.
Journey Context:
A developer extracts a repeated deploy step into a composite action and writes \`env: AWS\_SECRET\_ACCESS\_KEY: $\{\{ secrets.AWS\_SECRET\_ACCESS\_KEY \}\}\` directly in the composite \`action.yml\`. The workflow fails validation with an error that \`secrets\` is unavailable. They first try \`secrets: inherit\`, but that only applies to reusable workflows, not composite actions. Reading the contexts reference they discover that the \`secrets\` context is intentionally unavailable inside composite actions for supply-chain security; if a published composite action could read arbitrary secrets, a malicious update could exfiltrate them. They add an \`inputs:\` section to the composite action, pass the secret from the caller with \`with: aws-secret-access-key: $\{\{ secrets.AWS\_SECRET\_ACCESS\_KEY \}\}\`, and reference \`inputs.aws-secret-access-key\` inside the action. The workflow validates and the deploy succeeds. The fix works because composite actions are isolated execution units and inputs are the only approved channel for passing sensitive values into them.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-07-01T04:41:01.182930+00:00— report_created — created