codex - 💡(How to fix) Fix golangci-lint package loading fails in Codex sandbox without clear permissions diagnostic

What issue are you seeing?

I am opening a new issue because the previous ticket #5665 was closed with "Closing old issue", but the failure mode is still reproducible and the workaround is not discoverable.

golangci-lint fails inside the Codex macOS sandbox before analysis with:

Running error: context loading failed: no go files to analyze

This error is misleading. The repository contains valid Go packages, and ordinary Go tooling can load and test the module successfully:

go list ./...
go test ./...

Both succeed.

The failure occurs with both:

golangci-lint run ./...
golangci-lint run --fix ./...

Running with loader/debug output shows that golangci-lint invokes go list, but the loader returns zero packages:

level=debug msg="[loader] Built loader args are [./...]"
level=debug msg="[loader] starting GOROOT=/usr/local/go GOPATH=/Users/<user>/dev/go GO111MODULE= GOPROXY= PWD=/Users/<user>/SourceCode/<repo> go list -buildvcs=false -e -json=Name,ImportPath,Error,Dir,GoFiles,IgnoredGoFiles,IgnoredOtherFiles,CFiles,CgoFiles,CXXFiles,MFiles,HFiles,FFiles,SFiles,SwigFiles,SwigCXXFiles,SysoFiles,TestGoFiles,XTestGoFiles,CompiledGoFiles,Export,DepOnly,Imports,ImportMap,TestImports,XTestImports,Module -compiled=true -test=true -export=true -deps=true -find=false -pgo=off -buildvcs=false -- ./..."
level=debug msg="[loader] loaded 0 pkgs"
level=error msg="Running error: context loading failed: no go files to analyze: running `go mod tidy` may solve the problem"

Environment details, with PII redacted:

golangci-lint: 2.10.1, built with go1.26.0
go version: go1.26.2 darwin/arm64
module go.mod: go >= 1.26.2

GOPATH=/Users/<user>/dev/go
GOMODCACHE=/Users/<user>/dev/go/pkg/mod
GOCACHE=/Users/<user>/Library/Caches/go-build
GOROOT=/Users/<user>/dev/go/pkg/mod/golang.org/[email protected]
GOWORK=

I also tried adding writable roots to ~/.codex/config.toml:

sandbox_mode = "workspace-write"
approval_policy = "on-request"

[sandbox_workspace_write]
exclude_tmpdir_env_var = false
exclude_slash_tmp = false

writable_roots = [
  "/Users/<user>/Library/Caches",
  "/Users/<user>/dev/go",
]

After adding the relevant Go cache/toolchain paths to sandbox_workspace_write.writable_roots, the unelevated command still failed with the same package-loading error. The command only succeeded when rerun with elevated permissions in that updated configuration.

I have not verified whether elevated permissions alone would have fixed the original configuration. The important issue is that Codex does not surface this as a likely sandbox or permissions problem. Instead, the user-visible result is a golangci-lint package-loading failure that reports no go files to analyze, even though go list ./... and go test ./... succeed. In the full golangci-lint output, the tool also suggests that go mod tidy may solve the problem, but the observed workaround involved Codex-specific sandbox/elevation handling rather than a change to the Go module.

What steps can reproduce the bug?

1. On macOS, use a Go project that can be loaded and tested normally:

   go list ./...
   go test ./...

2. Use a Go setup where the module cache and downloaded Go toolchain are outside the repository, for example:

   GOPATH=/Users/<user>/dev/go
   GOMODCACHE=/Users/<user>/dev/go/pkg/mod
   GOCACHE=/Users/<user>/Library/Caches/go-build
   GOROOT=/Users/<user>/dev/go/pkg/mod/golang.org/[email protected]

3. Configure Codex with workspace-write and on-request:

   sandbox_mode = "workspace-write"
   approval_policy = "on-request"
   
   [sandbox_workspace_write]
   exclude_tmpdir_env_var = false
   exclude_slash_tmp = false
   
   writable_roots = [
     "/Users/<user>/Library/Caches",
     "/Users/<user>/dev/go",
   ]

4. Restart Codex.

5. Ask Codex to run:

   golangci-lint run -v ./...

6. Observe that package loading fails before any lint results are produced:

   level=debug msg="[loader] loaded 0 pkgs"
   level=error msg="Running error: context loading failed: no go files to analyze: running `go mod tidy` may solve the problem"

7. Ask Codex to rerun the same command with elevated permissions:

   Run `golangci-lint run -v ./...` with elevated permissions. It needs access to GOMODCACHE and the downloaded Go toolchain outside the repository.

8. Observe that the command now gets through package loading and reports real lint findings instead of the loader failure.

This appears to reproduce the same class of problem described in #5665, but the issue remains relevant for current Codex users because the ticket was closed without a product-side fix or discoverable workaround.

What is the expected behavior?

golangci-lint should be usable from Codex in a normal Go project without requiring users to rediscover this sandbox failure mode.

At minimum, Codex should detect this failure pattern and explain that the problem may be related to sandbox access or elevation, not necessarily missing Go files or an invalid Go module.

A better behavior would be one of:

• prompt for elevation when golangci-lint package loading fails with loaded 0 pkgs / no go files to analyze;
• provide a clear diagnostic explaining that GOMODCACHE, GOCACHE, or the downloaded Go toolchain may be outside the sandbox;
• document the required Codex configuration for common Go tooling;
• or provide a first-class way for trusted Go projects to allow access to Go module/build caches without requiring repository-specific instructions.

The current behavior is difficult to diagnose because Codex reports the golangci-lint package-loading failure as a normal tool failure. The visible error suggests that there are no Go files to analyze, even though go list ./... and go test ./... succeed. In the full golangci-lint output, the tool also suggests that go mod tidy may solve the problem, but the observed successful run required Codex-specific sandbox/elevation handling rather than a change to the Go module.

Additional information

This has a real usability cost. golangci-lint is a commonly used Go linter, and linting is often a required project gate. A new Codex user would not reasonably know that:

• go list ./... and go test ./... can succeed while golangci-lint package loading fails;
• the error message can be caused by sandbox access rather than by missing Go files;
• manually editing ~/.codex/config.toml may still not be sufficient;
• the working path may require explicitly asking Codex to run golangci-lint with elevated permissions.

This also does not seem like something every repository should need to document individually. If a common Go linter requires special Codex sandbox handling, Codex should either handle it directly or produce a targeted diagnostic.

Related closed issues:

• #5665: golangci-lint failure requiring elevated permissions
• #3720: related macOS Go tooling cache/sandbox issue