Caption checks generate files that should not all survive
A museum website workflow might download draft subtitles, normalize timing, produce a lint report, and compare language variants. Some of those outputs are ephemeral scratch files; others are the reviewed evidence for a release. GitHub Actions provides runner.temp and the corresponding RUNNER_TEMP environment variable to locate a temporary directory for the job. Using that directory is useful, but its name should not be mistaken for a secure erase promise. A responsible workflow explicitly distinguishes untrusted input, private working files, credentials, and approved reports before any content is uploaded or deployed.
Use the documented runner temporary location
GitHub documents runner.temp as a path to a temporary directory on the runner. It is emptied at the beginning and end of each job, subject to a stated limitation: files might remain if the runner account lacks permission to delete them. In a shell step, reference the environment value with the appropriate platform syntax instead of hard-coding a Linux or Windows path. The directory is a job-level scratch location, not a source repository path and not a durable artifact store. A workflow that needs stable references should create an explicit subdirectory and track its outputs.
Keep scratch paths separate from GITHUB_WORKSPACE
GITHUB_WORKSPACE points to the job working directory, typically where repository contents are checked out. runner.temp points to a different temporary area. Draft caption files created while executing an untrusted pull request should not be mixed with deployment credentials or published assets. Keep intermediate conversions in an identified scratch folder; copy only reviewed reports into an allowlisted evidence location. The distinction matters because uploads and deploy steps often use broad wildcard paths. A mistaken wildcard can include extra files regardless of which directory the job initially used.
Design cross-platform paths without guesswork
The actual runner temp path depends on the operating system and hosting environment. Use $RUNNER_TEMP in Bash, the environment variable syntax appropriate for PowerShell, or the runner.temp expression in workflow configuration. Quote paths to handle spaces and unusual characters. Resolve filenames from a controlled list rather than concatenating untrusted caption titles into filesystem paths. Normalize output names before creating files so that a subtitle label such as a relative traversal segment cannot escape the scratch directory. If a tool requires an absolute path, derive it from the documented runtime value rather than the developer’s workstation.
Avoid printing private captions into diagnostic logs
A temporary file can be confidential even when it is scheduled for deletion. CI tools often print failed commands, parser context, and snippets of files to logs. Configure the caption checker to report line numbers and error categories without exposing draft transcript text when that text is sensitive. Keep access tokens out of output files and never use scratch logs as a general credential store. Repository and workflow permissions still govern who can view logs and downloaded artifacts. Automatic masking and log retention policies cannot replace a deliberate decision about which content is appropriate to print.
Treat cleanup as an operation to verify
GitHub’s documentation explicitly warns that some files cannot be removed if the runner user lacks permission to delete them. This is especially relevant when a container or tool writes root-owned files and later shell steps run under another user. Use appropriate permissions at creation time, then check cleanup results in a safe teardown step. Do not attempt broad destructive cleanup outside the approved scratch directory. On persistent self-hosted runners, include runner hygiene and isolation in the organization’s security design instead of assuming a job-end promise covers every failure mode.
Retain evidence by deliberate selection
An approved caption report might be needed for a release audit, while raw normalized draft subtitles are not. Create a clear allowlist of report filenames, redact sensitive fields, and publish only after validation passes. Record the source commit, workflow run identity, and tool version with the report so it can be attributed accurately. A scratch folder deleted after the job is not a substitute for controlled evidence retention. Conversely, a report uploaded as an artifact is not proof that captions were approved; the workflow should record the human or policy gate that authorized release.
Test a workflow failure before shipping
In a staging repository, trigger a controlled caption-lint failure and verify where the diagnostic files are written and what the job logs reveal. Check that the finalization step reports unexpected leftover files, and verify that no draft transcript is included in any uploaded artifact. If the job is cancelled, the usual post-step sequence might not complete as expected, so document the runner’s residual-risk posture. This guide describes a test plan, not a test actually performed on your runners. A single successful run cannot establish the same behavior on every self-hosted configuration.
Recognize why a scratch folder is not a sandbox
Files created under runner.temp still inherit the job’s execution context and filesystem privileges. A compromised build step may read any content to which that process has access; the temporary path alone offers no isolation guarantee. Run untrusted pull request code with the least necessary permissions and keep deployment credentials out of those jobs. Use separate runners or workflows for privileged release operations where appropriate. If the QA process handles private oral-history transcripts, apply the organization’s collection data policy to the runner infrastructure and to every retention point.
Ship a clean and traceable caption review
The final release checklist should identify input subtitle versions, expected temporary output directories, approved report filenames, explicit cleanup status, and the review decision. Check a representative failure case before relying on the procedure. Keep a durable, access-controlled copy of approved evidence and avoid treating a deleted scratch file as proof that no other copies exist. runner.temp is a convenient documented location for ephemeral work; it does not guarantee zero residual files, secure deletion, or correct publication choices without operational controls.
How We Research
This November 11, 2026 article is a documentation-based instructional analysis, not a hands-on test or production benchmark. We compared GitHub Docs, Contexts reference — runner context and GitHub Docs, Variables reference — RUNNER_TEMP, identified the precise parameter or behavior that the documentation supports, and organized the guidance around an illustrative museum workflow. We did not run a live service request, inspect real WordPress content, measure accuracy, or verify delivery against a working customer account. Each pictured scenario is an original conceptual illustration; current settings, permissions, supported API versions, and organization-specific governance must be confirmed before use. The release checks deliberately distinguish technical output from authorization, evidence quality, and actual user outcomes.
Frequently Asked Questions
GitHub says the directory is emptied at job start and end, but files may remain if permissions prevent deletion.
No. The workspace holds checked-out project content; runner.temp is a separate temporary directory on the runner.
No. Export selected approved reports to a controlled artifact or archive location before the temporary directory is cleared.
No. It does not replace runner isolation, workflow permissions, or secret-handling controls.
Use a synthetic failing job, inspect remaining scratch paths and logs, and verify that no private input enters uploaded artifacts.