## TL;DR
The repository security-advisories list endpoint accepts a cwes filter, but each value needs the full CWE- prefix (CWE-79, not 79), and the global advisories endpoint does not accept the filter at all. A 422 means the parameter was rejected, not that there are no matching advisories. Fix the format, confirm you are on the endpoint that supports it, and filter client-side if the endpoint will not.

## The query

```text
GitHub security-advisories API: 422 on the `cwes` filter the agent copied from the docs
```

## Use this when

- The security advisories API returns 422 when you pass cwes
- The same request works without the filter
- You copied the parameter from docs or an example

## Not for

- 401 or 403 responses (authentication or permission problems)
- Pagination issues on the advisories endpoints
- Advisory data being wrong (a data problem, not a request problem)

## Steps

### 1. Identify exactly which endpoint you called

There are repository-level and global advisory endpoints, and they accept different parameters. Print the full request URL.

Expected output: certainty about which endpoint got the 422.

### 2. Format the CWE values with the prefix

```bash
curl -s "https://api.github.com/repos/[owner]/[repo]/security-advisories?cwes=CWE-79,CWE-89" | head -20
```

Expected output: a 200 response with advisories. The CWE- prefix on each ID is what the validator wants.

### 3. Read the 422 body before changing anything else

GitHub's 422 responses include an errors array describing what failed validation. Read it; it usually names the offending parameter precisely.

Expected output: confirmation that cwes (and not something else in the request) caused the rejection.

### 4. Fall back to client-side filtering

If you need CWE filtering on an endpoint that does not accept the parameter, fetch the advisories unfiltered and filter on the cwe_ids field in each advisory locally.

Expected output: the same filtered set, computed by you instead of the API.

### 5. Pin the working request in the agent's code

Store the exact working URL shape (endpoint plus parameter format) where the agent builds its requests, with a comment noting the prefix requirement. Verify: the agent's next advisories pull succeeds without a 422.

## Variant phrasings

### github security advisories api 422 cwes filter
The short symptom search.

### github api cwes parameter validation failed
The validation-first search.

Compatibility: GitHub REST API security-advisories endpoints. Parameter support varies by endpoint.

## Why it happens
API validators are literal: the cwes parameter is defined as a list of CWE identifiers in their canonical CWE-NNN form, and a bare number is not a valid identifier. Separately, the docs page the agent copied from may describe the repository endpoint while the agent called the global one, which never accepted the filter. Two different mistakes, one identical 422.

## Edge cases / pitfalls

- Always read the 422 error body. Guessing which parameter failed wastes more time than reading the message takes.
- Docs examples drift from the live API. When an example 422s, trust the error body over the example.
- Client-side filtering on large advisory lists needs pagination handled correctly, or you filter an incomplete set. That is a different silent-skipping bug; page fully first.
- Cache the advisory list locally when you filter client-side repeatedly. The advisories change slowly; your quota does not need to pay for every filter pass.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_-TlIkRfx1oOy00pGfDBbcQ