Support expression-based safe-outputs github-token from auth job outputs

[salekseev]

Summary

Today gh-aw rejects this pattern at compile time:

jobs:
  auth:
    outputs:
      token: \${{ steps.octo-sts.outputs.token }}
    steps:
      - uses: McK-Internal/octo-sts-action@v1
        id: octo-sts
        with:
          scope: owner/repo
          identity: workflow-name

safe-outputs:
  github-token: \${{ needs.auth.outputs.token }}
  create-issue:
    target-repo: owner/repo
    allowed-repos:
      - owner/repo

The schema appears to allow only \${{ secrets.NAME }}-style values for safe-outputs.github-token (and the per-handler github-token fields), which prevents using short-lived tokens minted earlier in the workflow.

Actual Behavior

Compilation fails before runtime with an error like:

'github-token': '\${{ needs.auth.outputs.token }}' does not match pattern '^\\$\\{\\{\\s*secrets\\.[A-Za-z_][A-Za-z0-9_]*(\\s*\\|\\|\\s*secrets\\.[A-Za-z_][A-Za-z0-9_]*)*\\s*\\}\\}$'

I saw the same compile-time failure in both places:

1. Top-level safe-outputs.github-token
2. Per-handler safe-outputs.create-issue.github-token

Expected Behavior

It would be useful if built-in safe outputs accepted expression-based tokens, at least for trusted workflow expressions like:

• \${{ needs.auth.outputs.token }}
• possibly other step/job outputs that resolve to a short-lived token

The built-in safe outputs already have logic to consume configured GitHub tokens; the blocker here is the schema/validation pattern, not the general idea of tokenized safe-output execution.

Why This Matters

This unlocks secure short-lived credential flows for built-in safe outputs without forcing users onto custom safe-outputs.jobs wrappers.

Two concrete examples:

1. Octo STS exchanges OIDC identity for a short-lived GitHub token based on a repo trust policy. This is a strong fit for cross-repo safe outputs because it avoids long-lived PATs or app private keys.
2. actions/create-github-app-token is another example of a token-minting action whose output is useful for downstream GitHub API operations.

In practice, this would let workflows do something like:

• mint a short-lived token in an auth job
• pass it via needs.auth.outputs.token
• let built-in safe outputs like create-issue / create-pull-request use that token directly

Current Workaround

Use a custom safe-outputs.jobs implementation instead of built-in safe outputs. That works, but it gives up the standardized built-in create-pull-request / create-issue path and requires hand-rolled git/API logic.

Request

Would you consider relaxing the validation/schema for safe-outputs.github-token and per-handler github-token so job output expressions like \${{ needs.auth.outputs.token }} are supported?

Even a constrained allowlist of expression shapes would be enough if broad arbitrary expressions are undesirable.

[salekseev]

Note: I hit this while testing whether built-in safe outputs could replace a custom safe-outputs.jobs PR/issue wrapper. The key limitation seems to be schema validation requiring secrets.* syntax for github-token, even though runtime token plumbing already exists for configured safe outputs.