What is the GITHUB_TOKEN available to a GitHub Actions job, and how long is it valid?

## Where the token comes from Every Actions job needs to talk back to GitHub — to post check results, comment on a pull request, push a tag, or read the repository it is building. Rather than making each team provision a credential for that, GitHub mints one automatically: when a job starts, it creates an installation access token tied to that repository and hands it to the job as `GITHUB_TOKEN`. When the job ends, the token is finished. This is the single most important security property of Actions and the reason a well-built workflow can hold no long-lived credentials at all. ## Lifetime The token is valid for the duration of the job and expires at the latest after 24 hours. Jobs are independent: two jobs in the same run get separate tokens, so a token cannot be smuggled forward except by explicitly passing it, and even then it dies with its own job's clock. Practically this means a token accidentally printed in a build log is a much smaller incident than a leaked personal access token — though GitHub also redacts known secret values from logs, and you should still treat it as a secret rather than relying on redaction. ## Scope and permissions The token can act on **the repository the workflow is running in**. It does not carry the permissions of the person who pushed the commit, and it does not reach sibling repositories in the same organisation. This is why the standard answer to "my workflow needs to check out a second private repository" is *not* GITHUB_TOKEN: you need a credential whose scope covers both repositories, which is a GitHub App installation token or a fine-grained personal access token. Within that repository, the token's permissions are adjustable, and the default is set at organisation or repository level. Many organisations set the default to read-only and let individual workflows request more where needed — the least-privilege posture, and a good thing to say out loud in an interview. For a pull request originating from a fork, the token is read-only regardless, which is what stops an outside contributor from opening a pull request whose workflow rewrites the base repository. ## The recursion guard A workflow that commits and pushes using GITHUB_TOKEN does **not** cause another workflow run for that push. GitHub suppresses it deliberately, because the alternative is an infinite loop: push triggers workflow, workflow pushes, which triggers the workflow again. This is why teams that genuinely want a bot commit to start downstream automation must use a different identity — commonly a GitHub App installation token — and it is a favourite follow-up question, because candidates who have only read the docs rarely know it. ## When GITHUB_TOKEN is not enough Reach past it only for a real reason: - Acting on **another repository** — a second checkout, a cross-repository dispatch. - Needing **organisation-level** access, such as managing teams. - Wanting downstream workflows to fire from actions the automation takes. In each case, the preferred replacement is a GitHub App installation token rather than a long-lived personal access token, because it is also short-lived and scoped to specific repositories and permissions. Authenticating to a **cloud provider** is a different problem again, solved with workload identity federation rather than with GITHUB_TOKEN, which has no meaning outside GitHub. ## How to answer Lead with the two facts that define it: minted per job, dies with the job; scoped to this repository, with configurable permissions and a read-only default in careful organisations. Then add the recursion guard and the fork read-only rule. Finishing with "and when it is not enough, a GitHub App installation token rather than a personal access token" shows you understand the credential ladder rather than just this one rung.