OpenHands recipe lock: PyJWT 2.14.0 relock closes ten advisories (unblocks the required osv-scanner check)

[seathatflowsinourveins]

Scope

• What this PR changes: relocks the OpenHands recipe lock from PyJWT 2.13.0 to 2.14.0 (three lines). Ten PyJWT advisories published 2026-09-29 affect 2.13.0; nine of them fail the required osv-scanner check (one pull_request log read; main push runs from 23:33Z on also concluded failure, logs not read), and the tenth (GHSA-w6j9-cwv2-h6wq) was ignored. OSV and GitHub list 2.14.0 as the first patched release for all ten. The change deletes that ignore and its IGNORE_SCOPES entry and rebinds the lock's IGNORE_ALLOWED_LOCKS entry (the two oauthlib advisories) to the relocked sha256, with a new receipt that carries the 2026-09-29 reachability review forward. oauthlib stays 3.3.1 (4.0.0 was published 2026-09-28T06:01Z, inside the 7-day window; its advisories stay ignored until 2026-10-13); its relock is tracked in Relock OpenHands onto oauthlib 4.0.0 / PyJWT 2.15.1 by 2026-10-08 (osv ignores from #517 expire 2026-10-13) #518 (owner bc, session native-agent-stack-bc; joint relock with PyJWT 2.15.1 earliest 2026-10-05T18:40:43Z, due 2026-10-08; a decision point at 2026-09-30T16:56:01Z, when PyJWT 2.15.0 leaves the window). Every window statement in the record is as of 2026-09-30T03:27:54Z.
• Authorization: the lock's owner session could not be reached on 2026-09-29 and is gone; the Gate A owner (2d) and the pi-practice session (a2) each asked the coordinator for this relock, and session 21, which had claimed it, withdrew and reviewed.
• Base commit: e45328d3 (main).
• Lane: lane:foundation (registering the files in manifests/evidence.json through the hot-file protocol does not make it shared).
• Owned paths touched: blueprints/runtime-workers/openhands/, .github/osv-scanner.toml, tests/test_osv_lockfile_coverage.py, docs/decisions/2026-09-22-github-automation-closure.md, evidence/receipts/, manifests/evidence.json (last commit).

SOTA sources

• PyJWT 2.14.0 (repository https://github.com/jpadilla/pyjwt, tag 2.14.0): released 2026-09-11, sdist sha256 77283c83fb56ecf566a886c757a714bc83668e38156de2cce8263302f42e0b86, wheel sha256 ad0cef71c756a56e74863c2919cf0985f72decbcfcb550ee2f422e7c62b5eedc (both equal the lock's hashes, read from the PyPI JSON API); CHANGELOG.rst v2.14.0 "Security" and "Fixed" sections, read from the sdist (it names nine of the ten advisories; the tenth's fix is listed under an id neither GitHub nor OSV serves).
• Advisories (GitHub global advisory API and OSV records, all first patched in 2.14.0, read 2026-09-30 and kept in the returned outputs, section H): GHSA-ffc3-869f-jxw9 (Critical, CVSS 9.1), GHSA-9j54-fg26-wv3r, GHSA-9v7f-9g4p-ffgj, GHSA-p4g4-x82p-q773, GHSA-r6x4-923q-g947, GHSA-w2cx-738m-mc7w (High), GHSA-2gx3-rcp4-g85q, GHSA-8wjv-2p76-3863, GHSA-hxm8-2xgr-2p9m, GHSA-w6j9-cwv2-h6wq (Medium).
• Method: OpenHands/software-agent-sdk@fcc102a697874d54a357e36004e02c95040dbdc0 (pins.json source_archive and uv_lock, both digests equal), astral-sh/uv@0.12.17 docs/concepts/resolution.md L142-L173 (environments, lockfile preferences), and this repository's 2026-09-27 relock in blueprints/runtime-workers/openhands/research.md (the same method with a fifth version-pinned upgrade).
• Scanner: google/osv-scanner v2.6.0, the workflow's own pinned binary (sha256 in .github/workflows/security-scan.yml) and command.
• Precedent: evidence/receipts/osv-oauthlib-pyjwt-reachability-20260929.json and its docs/decisions/2026-09-22-github-automation-closure.md entry.

Evidence-class table

Claim	Evidence class	Command / receipt
The new lock differs from the previous one in exactly lines 530-532 (the pyjwt line and its two hashes); both PyJWT 2.14.0 hashes equal PyPI's and the release is not yanked	source_review (structural comparison and registry read; not an execution)	evidence/relock-2026-09-30.txt sections C and D
The lock is reproducible: a fresh single-command run from the pinned SDK archive gives the same uv.lock and requirements.lock, byte for byte; uv lock, uv lock --check and uv export exit 0, cmp exits 0	local_integration (documented method, uv 0.12.17)	receipt locks[0].method; section C
The workflow's command over the 49 lockfiles exits 0 with no PyJWT ignore left; the previous lock under the same config exits 1 with the ten advisories	local_integration (local runs of the pinned scanner, not CI; this PR's own osv-scanner check is the CI run)	receipt osv_scanner.runs; section E
The recipe's hashed install sequence installs the new lock in a scratch venv on the host network, uv pip check passes and the SDK import check passes	local_integration (host scratch venv; no model request; not the image; not an OpenHands run)	receipt locks[0].install_check; section F
The 2026-09-29 oauthlib reachability review still holds at the new digest: PyJWT 2.14.0's wheel and sdist have no oauthlib reference (0 matches; the same search over requests-oauthlib's wheel gives 80)	local_integration (search with a positive control) plus source_review (unchanged inputs)	receipt carried_forward_review; section G
The same outcome for each test under oauthlib 3.3.1 and 4.0.0: import requests_oauthlib, google_auth_oauthlib.flow works and requests-oauthlib 2.0.0's own unit tests give 72 passed and the same 2 failed (timing assertions that also fail under 3.3.1)	unchanged upstream test code run by us on a scratch tree (pre-check for the follow-up relock; not applied)	receipt oauthlib_4_0_0_precheck; section J (full pytest output)

Local commands run

$ osv-scanner scan source --config .github/osv-scanner.toml --no-resolve <49 inventory lockfiles>   (2.6.0, no PyJWT ignore)
No issues found                                                                                       exit 0
$ osv-scanner scan source --config .github/osv-scanner.toml --no-resolve --lockfile=requirements.txt:<previous lock>   (control)
Total 1 package affected by 10 known vulnerabilities (1 Critical, 5 High, 4 Medium, 0 Low, 0 Unknown)  exit 1
$ uv lock --upgrade-package anyio==4.14.2 --upgrade-package click==8.5.0 --upgrade-package pypdf==6.19.0 --upgrade-package soupsieve==2.9.2 --upgrade-package pyjwt==2.14.0
Updated pyjwt v2.13.0 -> v2.14.0 (and the 09-27 updates)                                              exit 0; uv lock --check exit 0; cmp exit 0
$ python3 -B -m unittest tests.test_osv_lockfile_coverage tests.test_runtime_worker_openhands
Ran 151 tests ... OK                                                                                  exit 0
$ python3 scripts/validate.py
{"components": 69, "hashed_files": 8242, "profiles": 4, "receipts": 173, "status": "passed"}         exit 0
$ python3 scripts/evidence_manifest.py --check
{"files": 8242, "status": "passed"}                                                                   exit 0

The full unittest discovery runs in CI's validate check.

Decision record

docs/decisions/2026-09-22-github-automation-closure.md, dated addendum 2026-09-30 (alternatives: PyJWT 2.15.1 or 2.15.0, relocking oauthlib 4.0.0 now, extending the ignores to the nine; overturn: an advisory only a later PyJWT release fixes, an OpenHands run that fails with 2.14.0, a recorded reason for staying on 2.14.0 that no longer holds when PyJWT 2.15.0 leaves the window (2026-09-30T16:56:01Z), oauthlib 4.0.0 or PyJWT 2.15.1 clearing their windows on 2026-10-05; the follow-up relock has an owner and a due date of 2026-10-08 in #518).

Host evidence

This PR adds a receipt under evidence/receipts/, not evidence/hosts/.

• scripts/validate.py (exit 0 above) validates the receipt and its registration.
• Independent review: an Opus evidence-reviewer read head 11706fa (no defect in the lock change; two medium and six low record findings) and session 21 ran an evidence-reviewer and a stack-verifier that re-ran all seven commands (approve with nits; two medium and several low findings), then a delta check on the first repair (all text: as-of times, an owner name, a decision point for PyJWT 2.15.0, output labels). All findings are addressed in two repair rounds; session 21 was asked to check the second.
• No platform_status change.

Residuals

• The agent-server image's PyInstaller server binary is built from upstream's uv.lock, which still pins PyJWT 2.13.0, and the grader venv (OpenHands/benchmarks@405bae7's uv.lock, synced by install-grader.sh) pins PyJWT 2.10.1; neither is in the OSV inventory, and the 2026-09-28 grype record of the image predates these advisories. The relock covers the recipe venv only.
• No OpenHands task ran with the relocked venv; the install check ran on the host network.
• An installation that recorded the old lock digest must re-run install (host.py refuses to run it otherwise); this host has none.
• The oauthlib 4.0.0 (and PyJWT 2.15.1) relock is tracked in Relock OpenHands onto oauthlib 4.0.0 / PyJWT 2.15.1 by 2026-10-08 (osv ignores from #517 expire 2026-10-13) #518: earliest 2026-10-05T18:40:41Z, due 2026-10-08; on 2026-10-13 the two oauthlib ignores need renewal for the frozen Lumibot lock or that lock goes.
• The OSV database is live: a later advisory for any pinned package fails the check again.

Checklist

• No workflows or Actions are changed.
• No secrets are printed, logged or committed.
• No new paid hosting, subscription or billing surface.
• Peer-owned untracked files and worktrees were preserved.

🤖 Generated with Claude Code

[socket-security]

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

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	pypi/​pyjwt@​2.13.0 ⏵ 2.14.0	+1	+75

View full report