Done. I also cloned additional OpenHands org npm repos and checked them against the live Socket Mini Shai-Hulud feed. What I cloned • OpenHands/OpenHands • OpenHands/automation • OpenHands/extensions • OpenHands/typescript-client • OpenHands/trajectory-visualizer • OpenHands/community-pr-dashboard • OpenHands/vulnerability-fixer • OpenHands/openhands-agent-monitor • OpenHands/OpenHands-Web • OpenHands/Vibe • OpenHands/eval-monitor • OpenHands/llm-support-tracker • plus the already-present OpenHands/agent-canvas Method • I used Socket’s live Mini Shai-Hulud campaign page/article as the attack source. The page snapshot I inspected showed: ◦ Total packages: 1055 ◦ Last fetched: 2026-05-19 060954 UTC • Socket’s raw API endpoint was behind Cloudflare/403 from the shell, so I verified via the live campaign page plus exact Socket package pages for the overlapping dependencies I found. • I also scanned all cloned repos for high-signal IOCs from this campaign. Findings No confirmed exposure found in the scanned OpenHands repos. Repos with no suspicious overlap in manifests/lockfiles • extensions • typescript-client • trajectory-visualizer • community-pr-dashboard • vulnerability-fixer • openhands-agent-monitor • Vibe • eval-monitor • llm-support-tracker Repos with candidate overlap that I checked further • agent-canvas • OpenHands/OpenHands • OpenHands/OpenHands-Web • automation Candidate packages actually present • @tanstack/react-query ◦ 5.90.20, 5.96.2, 5.100.9 • @tanstack/query-core ◦ 5.90.20, 5.96.2, 5.100.9 • @tanstack/react-virtual ◦ 3.11.3 • @tanstack/virtual-core ◦ 3.11.3 • posthog-js ◦ 1.335.3, 1.372.6 What I verified about those candidates • I checked Socket package pages for the exact used versions of: ◦ @tanstack/react-query ◦ @tanstack/query-core ◦ @tanstack/react-virtual ◦ posthog-js • Those pages do not show the malicious-version banner/affected-versions notice that appears on known compromised packages. • I also verified the repos do not reference the clearly affected TanStack package family entries discussed in the campaign, such as: ◦ @tanstack/history ◦ @tanstack/router* ◦ @tanstack/setup Additional IOC scan results Across all scanned repos, I found no hits for: • router_init.js • router_runtime.js • tanstack_runner.js • @tanstack/setup • tanstack/router#79ac49eedf774dd4b0cfa308722bc463cfe5885c • filev2.getsession.org • git-tanstack.com • claude@users.noreply.github.com Bottom line • I did not find any confirmed dependency match or repo-level IOC indicating these OpenHands repos are currently hit by the npm supply-chain attack feed I checked. • The only overlapping ecosystem packages I found were safe-looking TanStack Query/Virtual packages and posthog-js, and their exact used versions did not present as affected on Socket. Recommended follow-up • Re-run this check before any release or dependency refresh, since the feed is growing quickly. • If you want, I can next produce a machine-readable audit report (repo → package → version → verdict) or add a small script/workflow to automate this check against future feed updates.

OpenHands encountered an error: The request to the Slack API failed. (url: <https://slack.com/api/chat.postMessage) The> server responded with: {'ok': False, 'error': 'invalid_blocks', 'errors': ['no more than 50 items allowed [json-pointer:/blocks]'], 'response_metadata': {'messages': ['[ERROR] no more than 50 items allowed [json-pointer:/blocks]']}} See the conversation for more information.

Done as far as permissions allow. Approved / clean: • OpenHands/OpenHands PR #14465 — https://github.com/OpenHands/OpenHands/pull/14465 • OpenHands/extensions PR #242 — https://github.com/OpenHands/extensions/pull/242 • OpenHands/extensions PR #243 — https://github.com/OpenHands/extensions/pull/243 Opened, but blocked on maintainer/admin-side repo restrictions: • OpenHands/automation PR #126 — https://github.com/OpenHands/automation/pull/126 ◦ Blocker: all fork workflow runs are

action_required

and require repo admin approval. ◦ Additional blocker:

automation/.github/workflows/pr-review-by-openhands.yml

explicitly skips fork PRs (

head.repo.full_name == github.repository

), so

all-hands-bot

review cannot happen on this fork PR. • OpenHands/typescript-client PR #171 — https://github.com/OpenHands/typescript-client/pull/171 ◦ Blocker:

CI

,

Integration Tests

, and

PR Review by OpenHands

fork runs are

action_required

and require repo admin approval. ◦ Additional blocker: the fork-safe

pull_request_target

review run was skipped because this PR has

author_association=NONE

, so it needs a maintainer-applied label/re-review trigger that I do not have permission to add. • OpenHands/trajectory-visualizer PR #51 — https://github.com/OpenHands/trajectory-visualizer/pull/51 ◦ Blocker:

Build

and

Test

runs are

action_required

and require repo admin approval. ◦ Additional blocker: the

pull_request_target

review workflow was skipped for the same

author_association=NONE

reason. ◦ Also shows failing

Vercel

on the fork PR. • OpenHands/community-pr-dashboard PR #33 — https://github.com/OpenHands/community-pr-dashboard/pull/33 ◦ Blocker: failing

Vercel

check on the fork PR. • OpenHands/vulnerability-fixer PR #51 — https://github.com/OpenHands/vulnerability-fixer/pull/51 ◦ Blocker: failing

Vercel

check on the fork PR. • OpenHands/eval-monitor PR #178 — https://github.com/OpenHands/eval-monitor/pull/178 ◦ Blocker: review is required, but the

pull_request_target

review workflow was skipped because this fork PR has

author_association=NONE

and needs a maintainer-side trigger. ◦ Also shows failing

Vercel

on the fork PR. • OpenHands/llm-support-tracker PR #91 — https://github.com/OpenHands/llm-support-tracker/pull/91 ◦ Blocker: failing

Vercel

check on the fork PR. Could not open PRs: • OpenHands/openhands-agent-monitor — upstream repo is archived/read-only • OpenHands/Vibe — upstream repo is archived/read-only Not touched, per your note: • OpenHands/OpenHands-Web Extra verification completed: • The separate extensions review-plugin PR (#243) includes the stricter 7-day dependency-age approval rule plus the simplified supply-chain sanity checklist. • Targeted tests passed there with: ◦

uv run pytest tests/test_pr_review_prompt.py tests/test_code_review_risk_evaluation.py -q

Current best state: • Fully green and bot-approved: 3 PRs • Open but blocked by org/repo permissions/settings: 7 PRs • Impossible to PR because archived: 2 repos

I redid the extensions change from

main

with a much smaller diff. What changed: • kept the existing review structure/checklist intact • only tightened the recency approval wording in: ◦

skills/code-review/SKILL.md

◦

skills/code-review/references/supply-chain-security.md

◦

plugins/pr-review/scripts/prompt.py

Testing: •

uv run pytest tests/test_pr_review_prompt.py tests/test_code_review_risk_evaluation.py -q

• result:

19 passed

New PR: • OpenHands/extensions PR #244 — https://github.com/OpenHands/extensions/pull/244 Current status: • branch created from

origin/main

• PR is open and non-draft • CI checks are passing except the in-progress

pr-review

job •

all-hands-bot

has been requested and the review workflow is currently still running

Yes —

automation

really does use npm. Concrete evidence: •

automation/frontend/package.json

•

automation/frontend/package-lock.json

•

automation/.github/workflows/ci.yml

has a

frontend

job that runs: ◦

npm ci

◦

npm run lint

◦

npm run test

◦

npm run build

So the automation PR is not useless on npm-usage grounds. What I rechecked: Repos with real npm usage: •

OpenHands/OpenHands

•

OpenHands/automation

•

OpenHands/typescript-client

•

OpenHands/trajectory-visualizer

•

OpenHands/community-pr-dashboard

•

OpenHands/vulnerability-fixer

•

OpenHands/eval-monitor

•

OpenHands/llm-support-tracker

Also npm-based, but archived/read-only so not in play: •

OpenHands/Vibe

•

OpenHands/openhands-agent-monitor

The one that was not meaningfully an npm dependency-update repo: •

OpenHands/extensions

◦ it has a packaging

package.json

, but no

package-lock.json

◦ no real npm install/update workflow surface ◦ its cooldown PR was the one that didn’t make sense Action taken: •

OpenHands/extensions

cooldown PR

#242

was already closed, so there was nothing left for me to close there. • I did not close the other cooldown PRs, because after rechecking, they are legitimate npm repos. Important distinction: • the separate

extensions

review-policy PR is still the valid one: ◦

OpenHands/extensions

PR

#244

— https://github.com/OpenHands/extensions/pull/244 So the correction is: • keep

automation

open • keep the other real npm repo PRs open • only the

extensions

cooldown PR was unnecessary, and it is already closed.

I did the first part, but I hit a real credentials blocker on the second part. Done: • Closed the old fork PRs: ◦

OpenHands/automation#126

◦

OpenHands/typescript-client#171

◦

OpenHands/trajectory-visualizer#51

◦

OpenHands/community-pr-dashboard#33

◦

OpenHands/vulnerability-fixer#51

◦

OpenHands/eval-monitor#178

◦

OpenHands/llm-support-tracker#91

• Rebuilt each change locally from current

origin/main

onto a fresh local branch: ◦ branch name in each repo:

enyst/dependabot-cooldown-npm-7d-repo

• Current local rebuilt branch heads: ◦

automation

→

d73618b

◦

typescript-client

→

77a745b

◦

trajectory-visualizer

→

663e1a3

◦

community-pr-dashboard

→

54b334b

◦

vulnerability-fixer

→

f387ee9

◦

eval-monitor

→

1462f6f

◦

llm-support-tracker

→

23488bb

Blocked: • I could not push any of those branches to

OpenHands/*

as repo branches. • I tested all GitHub credentials available to me: ◦

REMOTE_GH

◦

GITHUB_TOKEN

◦

SMOLPAWS_TOKEN

• All of them still get

403 Permission denied

on direct push to the org repos. So the current state is: • old fork PRs: closed • replacement upstream-branch PRs: not opened yet • replacement local branches: ready and clean What I need from you to finish: • either a GitHub token/account with

contents: write

on those

OpenHands/*

repos • or confirmation that there is another credential I should use for direct repo-branch pushes If you want, I can immediately retry the pushes/open-new-PR flow as soon as you point me at the correct writable credential.