fix: widen fastapi constraint for starlette CVE-2025-62727

[scale-ballen]

Summary

• Widens fastapi>=0.115.0,<0.116 to fastapi>=0.115.0,<0.136 in pyproject.toml
• This unblocks downstream consumers (agentex backend) from upgrading starlette to >=0.49.1, which fixes CVE-2025-62727 (HIGH severity)

Why

The <0.116 constraint was a conservative upper bound, not a compatibility requirement. The SDK uses only stable public FastAPI/Starlette APIs:

Import	Usage	Breaking risk
FastAPI	App construction, subclassing	None
Request	request.json(), request.headers	None
StreamingResponse	NDJSON streaming	None
BaseHTTPMiddleware	Request ID middleware	None
Depends	DI in adapter_redis	None

Test plan

• uv lock resolves: fastapi 0.135.1, starlette 0.52.1
• All 501 SDK tests pass (501 passed, 764 skipped)
• Zero new failures vs main branch

🤖 Generated with Claude Code

Greptile Summary

This PR widens the fastapi dependency constraint from >=0.115.0,<0.116 to >=0.115.0,<0.136 in pyproject.toml and regenerates uv.lock accordingly, bumping the resolved versions to fastapi 0.135.1 and starlette 0.52.1. The motivation is sound: the old tight upper bound was overly conservative and was blocking downstream consumers (agentex backend) from upgrading starlette to >=0.49.1, which is required to address CVE-2025-62727 (HIGH severity). The SDK's FastAPI surface area is minimal and entirely composed of stable public APIs (FastAPI, Request, StreamingResponse, BaseHTTPMiddleware, Depends), so the wide version range carries very low compatibility risk.

Key observations:

• The constraint change and uv.lock update are correct and well-motivated.
• Two new transitive dependencies appear in uv.lock: annotated-doc 0.0.4 and typing-inspection 0.4.2 — both are legitimate FastAPI 0.135.x runtime dependencies and are not security concerns.
• requirements.lock and requirements-dev.lock were not updated. These Rye-generated files still pin fastapi==0.115.14 and starlette==0.46.2 (the vulnerable version). CONTRIBUTING.md directs developers without Rye to use pip install -r requirements-dev.lock, meaning they would not receive the CVE fix. These files should be regenerated (rye lock) or removed/deprecated if the project has fully migrated to uv.
• The new <0.136 ceiling is tight against the latest resolved version (0.135.1). This is fine for now but will require another bump when FastAPI 0.136.0 is released.

Confidence Score: 4/5

• Safe to merge; the constraint widening is correct and well-tested, but requirements.lock files are out of sync with the CVE fix.
• The pyproject.toml change is minimal and correct, all 501 SDK tests pass, and the SDK only uses stable FastAPI public APIs. The one gap is that the Rye lock files (requirements.lock / requirements-dev.lock) were not regenerated and still reference the vulnerable starlette 0.46.2, meaning the dev-environment setup path documented in CONTRIBUTING.md does not benefit from the fix.
• uv.lock — the requirements.lock / requirements-dev.lock discrepancy should be addressed before or alongside this merge.

Important Files Changed

Filename	Overview
pyproject.toml	Widens the fastapi upper bound from <0.116 to <0.136 to allow starlette >=0.49.1 (CVE-2025-62727 fix); also bumps the package version to 0.9.4.
uv.lock	Lock file updated to fastapi 0.135.1 and starlette 0.52.1 (CVE-fixed); introduces two new transitive dependencies: annotated-doc 0.0.4 and typing-inspection 0.4.2. requirements.lock and requirements-dev.lock are NOT updated and still pin fastapi 0.115.14 / starlette 0.46.2 (vulnerable).

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["pyproject.toml\nfastapi >=0.115.0,<0.136"] --> B{Lock tool}
    B -->|uv lock| C["uv.lock\nfastapi 0.135.1\nstarlette 0.52.1 ✅\nCVE-2025-62727 patched"]
    B -->|rye lock\n⚠️ NOT RUN| D["requirements.lock\nrequirements-dev.lock\nfastapi 0.115.14\nstarlette 0.46.2 ❌\nCVE-2025-62727 unpatched"]
    C --> E["uv install\nDevelopers / CI using uv"]
    D --> F["pip install -r requirements-dev.lock\nDevelopers following CONTRIBUTING.md\nWithout Rye workflow"]
    E --> G["✅ starlette 0.52.1\nCVE fixed"]
    F --> H["❌ starlette 0.46.2\nCVE NOT fixed"]

Loading

Prompt To Fix All With AI

This is a comment left during a code review.
Path: uv.lock
Line: 83

Comment:
**`requirements.lock` / `requirements-dev.lock` not updated**

The `uv.lock` correctly resolves to `fastapi 0.135.1` and `starlette 0.52.1` (CVE-fixed), but the Rye-generated `requirements.lock` and `requirements-dev.lock` files were not regenerated. Both still pin the old, vulnerable versions:

```
fastapi==0.115.14
starlette==0.46.2   # CVE-2025-62727 unpatched
```

`CONTRIBUTING.md` explicitly instructs developers without Rye to bootstrap their environment using:

```sh
pip install -r requirements-dev.lock
```

Any developer (or CI job) following that path will still install `starlette 0.46.2` and not benefit from the CVE fix. Consider running `rye lock` / `rye sync` (or removing the Rye lock files if the project has fully migrated to `uv`) to bring them in sync with `uv.lock`.

How can I resolve this? If you propose a fix, please make it concise.

_{Last reviewed commit: e04bd4f}

Greptile also left 1 inline comment on this PR.

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	fastapi@​0.115.14 ⏵ 0.135.1	+1

View full report

[greptile-apps]

requirements.lock / requirements-dev.lock not updated

The uv.lock correctly resolves to fastapi 0.135.1 and starlette 0.52.1 (CVE-fixed), but the Rye-generated requirements.lock and requirements-dev.lock files were not regenerated. Both still pin the old, vulnerable versions:

fastapi==0.115.14
starlette==0.46.2   # CVE-2025-62727 unpatched

CONTRIBUTING.md explicitly instructs developers without Rye to bootstrap their environment using:

pip install -r requirements-dev.lock

Any developer (or CI job) following that path will still install starlette 0.46.2 and not benefit from the CVE fix. Consider running rye lock / rye sync (or removing the Rye lock files if the project has fully migrated to uv) to bring them in sync with uv.lock.

Prompt To Fix With AI

This is a comment left during a code review.
Path: uv.lock
Line: 83

Comment:
**`requirements.lock` / `requirements-dev.lock` not updated**

The `uv.lock` correctly resolves to `fastapi 0.135.1` and `starlette 0.52.1` (CVE-fixed), but the Rye-generated `requirements.lock` and `requirements-dev.lock` files were not regenerated. Both still pin the old, vulnerable versions:

```
fastapi==0.115.14
starlette==0.46.2   # CVE-2025-62727 unpatched
```

`CONTRIBUTING.md` explicitly instructs developers without Rye to bootstrap their environment using:

```sh
pip install -r requirements-dev.lock
```

Any developer (or CI job) following that path will still install `starlette 0.46.2` and not benefit from the CVE fix. Consider running `rye lock` / `rye sync` (or removing the Rye lock files if the project has fully migrated to `uv`) to bring them in sync with `uv.lock`.

How can I resolve this? If you propose a fix, please make it concise.