Google CodeMender: A Safe Pilot for Pull Request Security

Google released CodeMender v0.14.0 on 12 October 2026, followed by v0.15.0 on 14 October. The first update improves pull request scans, gives large files more time, keeps deep and diff scans in a unified session, and lets verification follow code that moved after the original finding. Version 0.15.0 improves SARIF output for GitHub Code Scanning and adds model-invocation counts to the JSON statistics report.

Those changes make CodeMender more practical to evaluate inside a software delivery workflow. They do not make it ready to approve or patch production code on its own. Google's documentation describes CodeMender as a limited Public Preview for supervised testing and evaluation. It says the product must not be used where serious errors cannot be corrected, or for commercial or production purposes.

That boundary should shape the pilot. The useful question is whether CodeMender can produce reviewable security evidence on pull requests, with predictable cost and acceptable false-positive rates. It is too early to treat it as an autonomous security gate.

What changed in the October updates

Version 0.14.0 made three changes that matter for pull request reviews:

• cm find --diff can detect removed security controls and has a configurable --diff-job-timeout for large files.
• Diff and deep scans now appear as single sessions in cm session list, cm report, and cm stats, which should make a review easier to trace.
• cm verify can locate code that moved after the initial scan and update the finding location.

The release also adds --deep-max-turns and --enable-bash, improves finding separation, and refines CWE classification for weak hashing and randomness. Each feature needs its own risk decision. Enabling shell commands, for example, expands what the scanning agent can do inside the workspace.

Version 0.15.0 updates SARIF 2.1.0 output with standard rule descriptors, severity properties, and repository-relative artifact locations. It also adds total, per-session, and per-turn model invocation counts to cm stats --json. A related fix keeps completed-turn token usage in session logs when a run exits because of an error or cancellation.

Start with a shadow pull request gate

Run the first evaluation on an internal test repository or a controlled replay of historical pull requests. Only use code that your organisation owns or is authorised to assess. Keep the result out of the merge decision while the team measures it.

In shadow mode, CodeMender reports findings next to the existing security toolchain. It does not replace static analysis, dependency scanning, secret detection, or mandatory human review. That comparison gives the security team a baseline: which introduced vulnerabilities did CodeMender find, which did it miss, and how often did it raise an issue that a reviewer dismissed?

Google documents three scan modes. A standard scan examines a repository broadly. A diff scan focuses on changed files and direct dependants, while separating pre-existing findings from issues introduced by the change. A deep scan performs a more exploratory audit and costs more time and tokens. For a pull request pilot, start with diff mode. Schedule deep scans separately and keep them out of the synchronous merge path.

Test the SARIF handoff

The v0.15.0 release should make CodeMender reports easier to ingest through GitHub Code Scanning. Test the handoff before using those alerts in a merge decision. Upload SARIF from the same replay set several times and check that rule identifiers remain stable, file locations resolve to the correct repository paths, severities map to the agreed review thresholds, and repeated scans do not create duplicate annotations.

Keep the CodeMender session ID with each uploaded report. The SARIF alert is the review entry point; the local session holds the scan, verification, and patch evidence. Reviewers need both when they challenge a finding or compare two runs.

Define the evidence chain

An agent-produced finding should move through an explicit evidence chain. The reviewer needs enough context to reproduce the result and challenge the agent's conclusion.

| Stage | Evidence to retain | Human decision | |---|---|---| | Scope | Base commit, changed files, dependent files, exclusions | Did the scan cover the affected area? | | Finding | Severity, CWE, source location, agent rationale | Is the finding specific enough to verify? | | Verification | Sandbox settings, proof-of-concept outcome, relevant logs | Is the issue reproducible in the intended environment? | | Candidate fix | Patch diff, build and test output, verification rerun | Should the patch be accepted, edited, or rejected? |

CodeMender's verification flow can generate and execute a proof of concept. Keep that work in an isolated environment with no production credentials, customer data, or unrestricted network access. A verified proof of concept is evidence for a reviewer. It is not permission to apply a patch.

This is the same principle we use when securing AI agents with runtime boundaries: the model's ability and its operating authority are separate design decisions.

Keep scanning and fixing separate

Do not let a pull request scan silently become an automatic remediation workflow. During the pilot, retain CodeMender's confirmation before file writes. Avoid -y, confirm_writes: false, --sandbox=false, and unrestricted execution.

If a finding deserves a proposed fix, create the patch on a separate candidate branch. CodeMender can apply a patch in its local sandbox, run the configured build and tests, and rerun verification. The resulting diff still needs code-owner review, normal CI, and the organisation's existing approval rules.

Separating the stages makes failures easier to diagnose. A weak finding, an unsafe proof of concept, and a bad patch are different problems. Combining them into one automated action hides which part failed.

Teams that already use spec-driven agentic workflows can treat the finding, verification result, and candidate patch as separate artefacts with separate acceptance criteria.

Measure the pilot like a security control

A useful pilot scorecard should cover quality, operational cost, and reviewer effort. Test on seeded vulnerabilities and authorised historical examples where the expected outcome is known.

Track at least:

• recall on vulnerabilities introduced by the test change;
• precision after a security reviewer verifies each finding;
• false-block rate at each proposed severity threshold;
• misses involving callers, callees, or files outside the changed hunk;
• median and 95th-percentile scan time;
• token use and cost per reviewed pull request;
• reviewer minutes per accepted finding;
• build, test, and verification outcomes for candidate patches;
• any attempted access beyond the repository and sandbox boundary.

The October updates make some of this easier to collect. Unified sessions connect diff and deep work, while cm stats --json now includes model invocation counts alongside token and timing data. Record invocations per reviewed finding and tokens per invocation. A rising invocation count can reveal retries or longer agent loops, but it does not show whether the extra work improved the result. Pair it with reviewer acceptance and verification outcomes.

Export these measurements into the team's evaluation record. Treat the product dashboard as operational evidence and keep the evaluation design in a separate, versioned record.

If model choice is part of the test, hold the repository and test set constant. Compare the cost of each successful reviewed finding, including its token use. The same cost-per-success logic applies to broader enterprise model routing.

Review data, access, and regional requirements

CodeMender runs through a local CLI and a hosted agent. Google's documentation says code snippets and tool results are sent to the service, while the full repository is not uploaded. It also states that data is retained for up to seven days and that VPC Service Controls are supported.

That still requires a data-flow review. Identify which repositories are eligible, what source fragments may leave the development environment, which project and service account can run the scan, and where session artefacts and local backups are stored. Use a dedicated identity with the minimum required permissions. Keep CI credentials out of the agent's workspace.

Google lists the service as globally available, but access remains limited during Preview. Organisations in the USA, UK, Saudi Arabia, UAE, and other markets should check whether the available location, contractual terms, retention period, and internal source-code policy fit the proposed test before enabling it.

Decide with exit criteria

Set the decision before the pilot starts. A team might proceed to a wider supervised evaluation only if CodeMender improves finding quality on the agreed test set, stays within latency and token budgets, and does not cross workspace or data boundaries. It should stop or be redesigned if reviewers cannot reproduce findings, the false-block rate is too high, or the required execution privileges are wider than the value justifies.

CodeMender's v0.14.0 and v0.15.0 changes make the pull request workflow easier to scope, trace, and measure. The Preview restrictions are equally important. Start with a bounded experiment that records evidence at every handoff and leaves patch approval with a person.

Bayseian helps enterprise teams design and evaluate governed AI systems. If you are planning an agent-assisted software security pilot, talk to our AI systems team about scope, evaluation, and production controls.

Primary sources

• Gemini Enterprise Agent Platform release notes, CodeMender v0.14.0 and v0.15.0 entries, 12 and 14 October 2026.
• CodeMender overview, updated 15 October 2026.
• Manage sessions and export reports, updated 15 October 2026.
• CodeMender find modes, accessed 15 October 2026.
• Integrate CodeMender with CI/CD, accessed 15 October 2026.
• Fix code vulnerabilities and manage diffs, accessed 15 October 2026.