[Windows][Go] Codex recursively searches GOMODCACHE with rg, causing severe system slowdown

Summary

When inspecting the source code of a Go dependency on Windows, Codex generated an rg command that unintentionally searched a very large portion of GOMODCACHE.

This caused extremely heavy disk I/O and made the entire Windows machine almost unresponsive.

The task only required searching a specific Go module/package, so recursively searching GOPATH/pkg/mod was unnecessary.

Environment

• OS: Windows 11
• Shell: PowerShell
• Codex version: v0.152.0 (to the best of my recollection)
• Model: GPT-5.6 Sol
• Language ecosystem: Go
• Search tool: ripgrep (rg)

Example

Codex generated a command similar to:

rg -n "type Conditions|ResourcePoolId" (go env GOPATH)\pkg\mod\ctyun-code.srdclo [...]

However, the output showed that rg was searching unrelated modules across the Go module cache, for example:

D:\AppData\go\pkg\mod\github.com\chromedp\cdproto@v0.0.0-20260321001828-e3e3800016bc\network\types.go:1551:type Conditions struct {
D:\AppData\go\pkg\mod\github.com\!azure!a!d\microsoft-authentication-library-for-go@v1.2.2\apps\internal\oauth\ops\wstrust\defs\saml_assertion_definitions.go:117:type Conditions struct {
...

This indicates that the effective search scope became much broader than the intended dependency.

On a mature Go development environment, GOMODCACHE may contain hundreds of thousands of files. A recursive rg scan causes very high filesystem activity on Windows and can make the machine nearly unusable.

Expected behavior

When Codex needs to inspect a Go dependency, it should resolve the exact package or module directory first rather than recursively searching GOMODCACHE.

For example:

go list -f '{{.Dir}}' <package-path>

or:

go list -m -f '{{.Dir}}' <module-path>

For an explicit module version:

go mod download -json '<module-path>@<version>' |
    ConvertFrom-Json |
    Select-Object -ExpandProperty Dir

Then rg should only search the resolved directory.

Workaround

I added the following instruction to my Codex configuration:

### Go dependency search safety

Never recursively search the entire `GOMODCACHE`, `GOPATH`, or `GOPATH/pkg/mod`. Do not manually construct module-cache paths or use version wildcards.

Resolve and verify the exact directory before searching:

- Package: `go list -f '{{.Dir}}' <package-path>`
- Selected module: `go list -m -f '{{.Dir}}' <module-path>`
- Specific version: `go mod download -json '<module-path>@<version>' | ConvertFrom-Json | Select-Object -ExpandProperty Dir`

After adding this rule, I have not encountered the system-freezing behavior again.

Suggested improvement

There are potentially two layers where this could be improved:

1. Agent behavior

   For Go dependency inspection, Codex should prefer Go-native dependency resolution (go list, go mod download) rather than constructing paths under GOPATH/pkg/mod and recursively searching them.

2. Command safety

   Codex could detect potentially expensive recursive searches such as:

   rg <pattern> <GOMODCACHE>
   rg <pattern> <GOPATH>
   rg <pattern> <home directory>
   

   and either narrow the search automatically or warn before executing it.

A generic guard against accidentally searching extremely large dependency caches could also benefit other ecosystems such as npm, Cargo, Maven, and Gradle.

Why this matters

This is more than a slow command. On Windows, recursively scanning a large module cache can generate enough filesystem and antivirus activity to make the entire desktop nearly unresponsive.

An agent should ideally avoid commands whose search scope is orders of magnitude larger than required.

Begin with the command-generation and execution paths for Go dependency searches, using the Windows PowerShell reproduction and the listed go list and go mod download commands as the behavioral reference. Done means searches are limited to the resolved package or module directory rather than the full GOMODCACHE, with coverage for the reported cache-wide recursive-search case.