Fixing an alert and updating your app
Check advisory evidence, choose what your agent may change, test the result and refresh your inventory.
Read the alert
Open an alert from the alerts list or from an app page. The alert page names the advisory in plain language, says how serious it is, and says how confident the match is: an exact or range match means a reported version matches the advisory, not that vulnerable code executes, while a name-only match is news about a component you use, with no version match confirming your app is actually affected.
Choose an agent handoff mode
Review only checks the evidence and reports recommendations without changing files. Review and apply fixes authorises the listed compatible fixes after those checks, so the agent can continue without another approval round. The app and alert pages offer both modes. In the CLI, use npx vibebeacon@latest review --name "My app" --mode apply; omit --mode for review only. The --mode flag needs vibebeacon 0.4.1, which is not on npm yet. The CLI prints a prompt. It does not edit your project.
Handoffs include the scan date, reported version, advisory links, recorded fixed versions and major-version risks. The CLI adds affected manifest, lockfile and installation paths when supported local npm evidence exists. Server prompts mark those paths unknown and ask the agent to inspect them. Verify every installed copy and check runtime, build and CI use against the advisory’s exploit conditions.
Approval is still required for major or breaking changes, deployment, publishing and destructive actions. Unrelated upgrades and secret access remain prohibited. Project approval boundaries still apply.
The fix plan groups packages into Fix now, Fix soon, When convenient, Dev tooling and No fix yet. These are review priorities, not estimates of score gain. The MCP review_app tool and GET /apps/:id/fix-plan retain their review-only default; the CLI and website add the explicit mode choice.
No fixed version recorded
Choose whether to upload
Select upload in the website handoff or add --upload to review. The generated prompt explicitly authorises sending the documented scan JSON to https://vibebeacon.app/api/v1/manifests using an already configured credential. It names the payload fields and excludes source code, paths, dependency trees, environment values and credentials. It does not authorise another destination.
Without that choice, the agent may produce a local scan after fixes and must ask before sending it. Run npx vibebeacon@latest login yourself if a credential is needed; do not paste a key into a prompt.
Test and compare the next scan
Run relevant tests, build and lint for compatible upgrades too. Preserve the app ID and full scan scope. When there is no app ID, keep the existing name so the upload reaches the same app. Inspect the new, resolved and reopened alert IDs, reasons and remaining count.
Inventory refreshed means the upload was accepted. A changed version can resolve an inventory match, but deployment and exploitability remain unverified. An omitted package or reduced scan scope is never a verified fix. Pending processing and missing previous scans limit comparisons. See scan results and read-only findings.
Snooze, acknowledge, resolve, or not applicable
Acknowledge
Says you have read it. It stays open and stays on the dashboard, but drops out of the digest until something changes.
Snooze 7 days
Hides it for a week, then it comes back open. For a fix that has to wait for the next sprint.
Resolve
Marks it done by hand. If the next manifest still shows the affected version, it reopens rather than staying quietly wrong.
Not applicable
For when you or your AI tool checked and the advisory does not apply to how this app uses the package. Give a reason of at least 10 characters; it shows on the alert as “Checked by …: not applicable”, with the reason underneath.
These are workflow statuses, not security evidence. A later scan can reopen a resolved alert if the affected version returns. Record supporting evidence before using a not-applicable verdict; a higher score does not prove safety.
News-only alerts
A name-only alert means a vendor post or news item mentioned something in your stack with no version data attached. Nothing confirms your app is affected. Read it, decide whether it applies to how you use that component, and acknowledge or resolve it either way. It carries no upgrade command because there is nothing specific to run.
More on how alerts work
Severity, match confidence, and what triggers an instant email versus a digest are covered in Alerts and digests. The manifest format itself, including what a name change does and does not do, is in Manifest format.
- Read the evidence and choose review only or authorised compatible fixes.
- Ask before major changes and test every fix.
- Upload only with consent, preserve app identity and scope, and inspect change reasons.
- Snooze or acknowledge if the fix has to wait; resolve if you fixed it by hand; mark not applicable if it does not apply here.