claude-code - 💡(How to fix) Fix IDE diagnostics ignore workspace gopls build env (GOOS/GOARCH)

Summary

When using the VS Code extension on a non-Linux host (macOS, in my case) with a Linux-targeted Go project, Claude Code's IDE diagnostic surface (<ide_diagnostics> / <new-diagnostics> system reminders) contains errors that do not appear in VS Code's own Problems pane. The errors are characteristic of the type-check running under the host's darwin/arm64 build context rather than the workspace's configured linux/amd64 context.

Repro

1. Open a Go project that has files tagged //go:build linux and uses Linux-only golang.org/x/sys/unix symbols (any of: siderolabs/talos, kubernetes/kubernetes, anything netlink-heavy).

2. On macOS, configure .vscode/settings.json:

   {
     "gopls": { "build.env": { "GOOS": "linux" } },
     "go.toolsEnvVars": { "GOOS": "linux" }
   }

3. Open the project in VS Code with the Claude Code extension.

4. Open any Linux-only file. VS Code's Problems pane is clean (gopls honors the workspace env).

5. Ask Claude to edit a file in the same package. Note that the <new-diagnostics> reminder injected back into Claude's context contains errors like:

   • undefined: unix.ARPHRD_ETHER
   • undefined: unix.PidfdOpen
   • undefined: unix.SYS_PROCESS_MRELEASE
   • undefined: unix.IFLA_BR_STP_STATE
   • undefined: unix.Timex
   • undefined: unix.MOUNT_ATTR_NODEV
   • undefined: block.NewFromPath, xfs.UnixRoot, etc.

   These symbols exist on Linux and are visible to gopls under the workspace build env. They do not appear in the VS Code Problems pane.

Expected

The diagnostic surface fed back to Claude should match what gopls (the workspace's language server) is actually evaluating — i.e. honor .vscode/settings.json's gopls.build.env / go.toolsEnvVars.

Actual

Claude's diagnostic collection appears to run a supplementary type-check pass under the host environment, bypassing the workspace gopls config.

Impact

• The agent chases phantom errors that don't exist in the actual build.
• Token waste triaging diagnostics that turn out to be host-arch artifacts.
• Real (non-host-arch) errors get diluted by noise, harder to spot.
• I've twice had to tell my session "ignore those, gopls is clean" after the agent reacted to them.

Requested fix (any one)

1. Add a claudeCode.diagnosticsEnv setting in ~/.claude/settings.json / project .claude/settings.json that propagates env vars to the diagnostic pass:

   { "diagnosticsEnv": { "GOOS": "linux", "GOARCH": "amd64" } }

2. Or: have the diagnostic collector honor .vscode/settings.json's gopls.build.env and go.toolsEnvVars directly.
3. Or: route diagnostics exclusively through mcp__ide__getDiagnostics (which reflects VS Code's actual Problems pane) rather than running a parallel type-check.

Option 3 seems simplest and would also reduce duplicated work between VS Code and Claude.

Environment

• Claude Code VS Code extension on macOS (darwin/arm64).
• VS Code's gopls reports zero errors (confirmed in Problems pane).
• Target project: go.mod with go 1.26.3, Linux-targeted package mix.