chore: Bump code-client-go - get the file filter from the invocation context

[danskmt]

Pull Request Submission Checklist

• Follows CONTRIBUTING guidelines
• Commit messages are release-note ready, emphasizing what was changed, not how.
• Includes detailed description of changes
• Contains risk assessment (Low | Medium | High)
• Highlights breaking API changes (if applicable)
• Links to automated tests covering new functionality
• Includes manual testing instructions (if necessary)
• Updates relevant GitBook documentation (PR link: ___)
• Includes product update to be announced in the next stable release notes

What does this PR do?

Bumps code-client-go from v1.31.1 to v1.31.3.

In v1.31.3, snyk code test's file listing obtains its file filter from the invocation context (invocationCtx.GetFileFilter(...)) instead of constructing one locally. The filter therefore arrives already wired to the invocation's configuration, which means filtering behaviour the framework gates on configuration now takes effect for Snyk Code.

No CLI code changes are needed; this is the go.mod/go.sum bump only.

Where should the reviewer start?

• cliv2/go.mod and cliv2-private/go.mod — the version bump, identical in both runtimes
• cliv2/go.sum, cliv2-private/go.sum — corresponding checksums

How should this be manually tested?

Use a repository whose absolute path contains regex metacharacters, containing:

• .gitignore with *.log and node_modules
• node_modules/lib/index.js (untracked, matched by the node_modules rule)
• src/app.js (not matched by any rule)

Then run, from a build of this branch:

INTERNAL_SNYK_FILE_FILTER_METACHARACTER_FIX_ENABLED=false snyk code test "$PWD" -d
INTERNAL_SNYK_FILE_FILTER_METACHARACTER_FIX_ENABLED=true snyk code test "$PWD" -d

Expected, from the Snyk Code file filtering and Coverage report lines:

metacharacter fix	files into filter	scanned	.js files
false	4	2	2 — node_modules/lib/index.js is not excluded
true	3	1	1 — only src/app.js

What's the product update that needs to be communicated to CLI users?

None for this bump on its own. The filtering fixes it enables are feature-flagged and announced with their own rollouts.

What are the relevant tickets?

CLI-1717

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[snyk-pr-review-bot]

PR Reviewer Guide 🔍

🧪 No relevant tests

🔒 No security concerns identified

⚡ No major issues detected

📚 Repository Context Analyzed This review considered 5 relevant code sections from 4 files (average relevance: 1.00) CLAUDE.md (2 segments, lines 227-313) scripts/upgrade-snyk-go-dependencies.go (lines 1-149) package.json (lines 1-236) package-lock.json (lines 6-266)

🤖 Repository instructions applied (from AGENTS.md)

[cursor]

Automatically approved — this PR is only a dependency version bump (no source code changes in this repo).

Scope verified: the diff touches exactly 4 files, all mechanical version/checksum updates: cliv2/go.mod, cliv2/go.sum, cliv2-private/go.mod, cliv2-private/go.sum, bumping github.com/snyk/code-client-go from v1.31.1 → v1.31.3 consistently across both modules.

Verification performed (semantic analysis, adversarial review, security scan, and code review, all with no findings):

• Both go.sum checksum pairs match the public Go checksum transparency log (sum.golang.org) byte-for-byte — no tampering.
• v1.31.3 is a legitimate, tagged upstream release (commit e316c23, PR snyk/code-client-go#171) described upstream as a no-behavior-change refactor; the intervening v1.31.2 is a CI-only release.
• cliv2 builds and vets cleanly against the new version (go build ./..., go vet ./..., go mod verify all pass); go mod tidy produces zero diff.
• No known security advisories for code-client-go at either version.
• // indirect scoping differences between cliv2/go.mod (direct) and cliv2-private/go.mod (indirect) match the pre-existing pattern for every other shared extension dependency — not introduced by this PR.

Per this automation's policy, dependency-bump-only changes are auto-approved; any change that touches source code would not be.

  

_{Sent by Cursor Automation: Automatic PR verification}