Yes, they can on a shared machine. GitHub's guidance warns that secrets passed as command line arguments can be visible to other jobs running on the same runner, for example through the process list. Pass secrets through environment variables or input files, and avoid sharing a runner between jobs with different trust levels.
Why arguments leak
A command line is part of a process's visible state on most operating systems. Anyone who can list processes on the same machine can see the full command, including every argument. On a GitHub-hosted runner that is not a concern, because each job runs in its own ephemeral, isolated virtual machine, as GitHub describes. On a self-hosted runner that runs several jobs, or one that stays up between jobs, the picture changes.
GitHub's documentation gives the example of ps x -w showing arguments of other processes. Masking in the logs does not help here, because the exposure is on the machine, not in the log.
When this applies
| Runner setup | Risk from arguments |
|---|---|
| GitHub-hosted, one job per virtual machine | Low, the machine is isolated and thrown away |
| Self-hosted, several runner processes on one host | Real, jobs share a process list |
| Self-hosted, persistent, serving many repositories | Real, and compounded by leftover files |
| Self-hosted, just in time, one job then removed | Lower, though reused hardware can still expose information unless reset |
GitHub notes that just in time runners perform at most one job before being removed, and that reusing hardware can still expose information unless the environment is reset.
Safer ways to pass a secret to a command
- Environment variable. Set the secret in the step's
envblock, scoped to the one step that needs it, and have the program read it from there. Environment values are still visible to processes owned by the same user in some systems, but they are not part of the command line shown by a plain process listing. - Standard input. Many tools accept a secret from stdin. Pipe it in, so it never appears in the arguments.
- A file with tight permissions. Write the secret to a temporary file with owner only access, point the tool at it, and remove it after the step.
- A credential helper or short-lived token. Where the tool supports it, fetch a short-lived credential at run time instead of handling a long-lived one. See GitHub Actions OIDC.
Reduce who shares the machine
Arguments only leak to people who share the host. So reduce the sharing.
- Use runner groups so a runner serves only the repositories you choose. GitHub recommends groups to limit the impact of a compromise.
- Do not run jobs from public repositories or forks on a persistent self-hosted runner. See should public repository pull requests run on self-hosted runners.
- Prefer ephemeral runners that take one job and go away. See ephemeral vs persistent CI runners.
- Keep deploy jobs on runners that do not run untrusted build code.
A quick audit
Search your workflows for run: lines that include a secret expression directly in a command, such as a flag followed by a secrets value. Each match is a place where the value becomes an argument. Move it to an environment variable on that step.
Quick check
Does masking hide an argument from other processes?
No. Masking redacts log output on the runner. It does not change what the operating system shows in a process listing.
Is this a problem on GitHub-hosted runners?
Much less so, since GitHub describes them as ephemeral, clean and isolated virtual machines. The concern is mainly shared self-hosted hosts.
Sources
Last reviewed: 19 October 2026.
