After #450 the alert count went 55 → 48 (2 critical, 20 high, 24 medium, 2 low). The remainder is not reachable from the shipped application, and this issue records why so the number isn't misread as a production emergency.
The shipped app has four runtime dependencies
apps/desktop/package.json dependencies:
@sentry/electron ^7.18.0
@sentry/react ^10.73.0
electron-log ^5.4.4
electron-updater ^6.8.9
None of the alerting packages are among them. Every remaining alert arrives through dev tooling — devtools, build tooling, test infrastructure — none of which is bundled into a production build.
Where the biggest sources come from
| Package |
Alerts |
Reached via |
hono |
16 |
agent-react-devtools → @modelcontextprotocol/sdk → @hono/node-server |
fast-uri |
7 |
ajv, via the same MCP SDK chain |
tar |
6 |
electron-builder / node-gyp toolchain |
brace-expansion |
4 |
transitive under glob/minimatch across dev tooling |
ip-address |
3 |
socks proxy chain under dev tooling |
agent-react-devtools is a devDependency and no-ops in production (import.meta.env.PROD check — see .claude/rules/agent-react-devtools.md), so the hono chain — a third of all remaining alerts — cannot reach users.
Why Dependabot still flags them
Alerts are raised against pnpm-lock.yaml without distinguishing dev from runtime scope, so dev-only tooling shows up with the same severity as shipped code.
Suggested handling
Not urgent, but worth a deliberate pass rather than leaving 48 open indefinitely:
- Bump the direct dev dependencies that own these chains (
agent-react-devtools, electron-builder) and see how many resolve transitively.
- For anything remaining with no upstream fix, use
pnpm.overrides to force a patched transitive version — the existing @types/node pin is the precedent.
- Dismiss what is genuinely unreachable, with a recorded reason, so the count reflects real exposure.
Worth confirming
Whether Dependabot can be configured to separate dev-scope from runtime-scope alerts here — that would keep the count meaningful without manual triage each time.
After #450 the alert count went 55 → 48 (2 critical, 20 high, 24 medium, 2 low). The remainder is not reachable from the shipped application, and this issue records why so the number isn't misread as a production emergency.
The shipped app has four runtime dependencies
apps/desktop/package.jsondependencies:None of the alerting packages are among them. Every remaining alert arrives through dev tooling — devtools, build tooling, test infrastructure — none of which is bundled into a production build.
Where the biggest sources come from
honoagent-react-devtools→@modelcontextprotocol/sdk→@hono/node-serverfast-uriajv, via the same MCP SDK chaintarbrace-expansionip-addressagent-react-devtoolsis a devDependency and no-ops in production (import.meta.env.PRODcheck — see.claude/rules/agent-react-devtools.md), so thehonochain — a third of all remaining alerts — cannot reach users.Why Dependabot still flags them
Alerts are raised against
pnpm-lock.yamlwithout distinguishing dev from runtime scope, so dev-only tooling shows up with the same severity as shipped code.Suggested handling
Not urgent, but worth a deliberate pass rather than leaving 48 open indefinitely:
agent-react-devtools,electron-builder) and see how many resolve transitively.pnpm.overridesto force a patched transitive version — the existing@types/nodepin is the precedent.Worth confirming
Whether Dependabot can be configured to separate dev-scope from runtime-scope alerts here — that would keep the count meaningful without manual triage each time.