Repository navigation
Docs: guidelines for configuring Go module/build cache in a security-conscious way #27886
Description
Problem
There is no dedicated guidance on how to configure Go module and build caching in Agentic Workflows in a security-conscious way. The relevant information is currently spread across several reference pages (frontmatter.md, sandbox.md, cache-memory.md) with no Go-specific caching example.
The gap becomes visible when a workflow uses the cache: frontmatter field or a jobs.setup pre-build step to cache ~/go/pkg/mod and ~/.cache/go-build — there are real security trade-offs here that aren't covered today:
- Cache poisoning: a cached Go module tarball is not re-verified against the checksum database (
GONOSUMCHECK,GONOSUMDB) on restore. GOMODCACHEvsGOCACHEscope: caching the module download cache and the build cache have different risk profiles; mixing both in oneactions/cacheentry is common but worth calling out.- Integrity interplay: when a workflow uses
tools.github.min-integrity, should the Go module cache be scoped to the same integrity level? The current docs don't address this. - Writable paths in the sandbox: as noted in the smoke-copilot fixture, the default
GOCACHE/GOMODCACHElocations may not be writable inside the AWF sandbox, requiringGOCACHE=/tmp/go-cache GOMODCACHE=/tmp/go-mod— but this isn't documented for end-users.
Requested documentation
A dedicated section or guide covering:
- Recommended
cache:frontmatter for Go — which paths to include, recommended key structure (go-${{ hashFiles('go.sum') }}), and restore-key fallback strategy. actions/setup-gobuilt-in cache option — whethercache: trueon the runtime setup action is supported and safe in the AWF context.- Go cache paths in the AWF sandbox — clarify whether
~/go/pkg/modand~/.cache/go-buildare writable, and when to redirect viaGOCACHE/GOMODCACHEenv vars. - Security considerations — checksum verification on restore, risks of sharing a module cache across branches/PRs of differing integrity, and recommended mitigations.
jobs.setuppre-build pattern for Go — a concrete example analogous to the Gradle example insandbox.md(line 287).
Context
- Discovered while exploring the
cache:field in.github/workflows/prompt-clustering-analysis.md. - Current docs:
reference/frontmatter.md(§ Cache Configuration),reference/sandbox.md(§ Caching section),reference/cache-memory.md,reference/supported-languages.md.
🤖 Created by Claude Code
Activity
pelikhan commentedon Oct 7, 2026
Status (2026-10-07; Needs progress check): The April 22 request identifies a gap in Go-specific cache guidance, including sandbox paths and the differing risks of module and build caches. The issue is open and needs a progress check against current documentation before drafting guidance and an example.
pelikhan commentedon Oct 16, 2026
Current-state refresher (2026-10-16): partially addressed; the documentation gap is narrower than the opening report. #37583 merged on June 7 and added a dedicated Go cache FAQ: module/build paths, an OS-and-
go.sumcache key, restore keys, ajobs.setupexample,setup-gowithcache: false, and warnings about writable caches crossing trust boundaries. The sandbox reference also documents explicitGOMODCACHE/GOCACHEpaths.The fuller security questions in this issue are not answered there: the differing integrity risks of module versus compiled build caches, what integrity verification on restore actually guarantees, and the relationship to
tools.github.min-integrity. The example alone also does not establish writability for every runner/sandbox configuration. Remaining work is to resolve those specific questions, rather than start a Go caching guide from scratch. Assessment is against current default-branch source; no cache restore was exercised.pelikhan commentedon Oct 22, 2026
Relevance check (2026-10-22): keep open for the narrower cache-integrity guidance gap, not missing Go examples. On current
main(ffdd9c9), the Go FAQ and sandbox cache-path section from merged #37583 already supply paths, OS/go.sumkeys, restore prefixes,jobs.setup,setup-gowithcache: false, and a trust-boundary warning. I checked actual merged doc changes in #68663, #70500, and #71114: none adds the missing Go-cache integrity treatment; merely mentioning this issue in a documentation PR is not completion.One important distinction is now explicit elsewhere: cache-memory has integrity-level/policy-key isolation, whereas
tools.github.min-integrityfilters GitHub tool content. Neither reference establishes automatic integrity partitioning or authentication of an arbitrary top-level Gocache:archive.Next concrete action: extend the existing FAQ, rather than create a duplicate guide, to distinguish module-source versus compiled build-cache trust; explain what restore does/does not verify and where
go mod verify/checksum settings apply; define key, restore-prefix, and writer policies across trust levels; and state that cache-memory isolation is a different feature. Also clarify the supportedsetup-go cache: truealternative versus deliberatecache: falseownership and show the correct same-job setup/agent handoff plus runner-specific writable-path expectations. The current example alone does not establish those runtime properties; no cache restore or sandbox execution was performed here.