fix(devtools): read viewer database from server config only (VULN-11550)

[gr2m]

Background

The DevTools viewer's /api/notify endpoint stored a dbPath taken from the (unauthenticated) POST body into a module-level remoteDbPath, and every API read called reloadDb(remoteDbPath), which passed it straight to fs.existsSync / fs.readFileSync with no validation. Any web page a developer visited while the viewer was running could therefore point the viewer at an arbitrary file:

• Arbitrary file read — JSON files containing a runs array are returned verbatim via /api/runs (e.g. another project's .devtools/generations.json); other targets act as a JSON-validity / file-existence oracle.
• DoS — a dbPath of /dev/zero or a multi-GB file hangs / OOMs the synchronous readFileSync.
• The poisoned path is module-level, so a single POST persists until the viewer restarts.

This is VULN-11550 (ANT-2026-R88SY5T6). It is distinct from VULN-11530 (fixed in #16042), which only addressed reachability (wildcard CORS, 0.0.0.0 bind, Host/Origin allowlisting) and left this sink in place.

Summary

Determine the viewer database location from server-side configuration only — never from a network request:

• reloadDb() no longer accepts a path argument. It reads only the configured location: the default <cwd>/.devtools/generations.json, or the new AI_SDK_DEVTOOLS_DB_PATH env var when the viewer runs in a different directory than the app.
• /api/notify ignores any dbPath in the request body (it remains a pure "data changed → reload" signal); the module-level remoteDbPath is removed.
• Database reads go through a shared helper that requires a regular file (statSync) under a 100 MB cap, closing the /dev/zero / huge-file DoS vector.

Common usage (viewer launched from the project root) is unchanged — <cwd>/.devtools/generations.json already resolves to the file the SDK writes.

Manual Verification

• Grepped every call site: there is no remaining reloadDb(<network value>) and no remaining reference to remoteDbPath; the only inputs to the read are process.cwd() and the AI_SDK_DEVTOOLS_DB_PATH env var.
• Confirmed the default configured path (<cwd>/.devtools/generations.json) is byte-identical to the DB_PATH the SDK writes to, so a viewer started in the project root behaves exactly as before.
• Confirmed the statSync + size-cap helper rejects a non-regular path (directory/device) without throwing, so a hostile or missing path degrades to an empty DB rather than hanging.

Checklist

• All commits are signed (PRs with unsigned commits cannot be merged)
• Tests have been added / updated (for bug fixes / features)
• Documentation has been added / updated (for bug fixes / features)
• A patch changeset for relevant packages has been added (for bug fixes / features - run pnpm changeset in the project root)
• I have reviewed this pull request (self-review)

Future Work

• Document the new AI_SDK_DEVTOOLS_DB_PATH env var alongside AI_SDK_DEVTOOLS_PORT in the devtools docs.
• Assess whether @ai-sdk/devtools exists on the release-v6.0 / release-v5.0 branches and backport if applicable.

Related Issues

• Fixes VULN-11550 (Linear / ANT-2026-R88SY5T6).
• Follow-up to fix(devtools): secure devtools viewer api access #16042 (VULN-11530), which fixed the reachability side of the same endpoint.

[gr2m]

Closing in favor of #16049 (same fix for VULN-11550, owned by the issue assignee).

Per the comparison: #16049 validates + confines the notify dbPath (basename generations.json under .devtools, statSync isFile, and realpathSync symlink-escape rejection) with zero behavior change for the cross-directory viewer case, and it uniquely guards against symlink escape. The only gap vs this PR is the absence of a read-size cap, which I'll graft onto #16049.

This PR took the stricter "don't accept any network path" approach (matching the report's literal suggested fix) but at the cost of requiring AI_SDK_DEVTOOLS_DB_PATH for cross-CWD viewers. We're going with the lower-risk path.

[gr2m]

duplicate of #16049