[Plugin] adding harness detection and install session ID

[Melkeydev]

This PR adds detection logic for which harness the plugin is installed for + an instal ID for first time users who install the Plugin

[alexfarnhambrown]

Thanks for landing on this, @Melkeydev! Stoked to drive the downstream modeling work.

[socket-security]

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

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	npm/​detect-agent@​1.2.0

View full report

[alexfarnhambrown]

Three inline notes from the downstream side, plus one proposal that spans both files.

Proposal: carry agentHarness on active-session.json too.

Right now harness only exists in the plugin phone-home, capped at once per harness per UTC day, so a CLI invocation can't be attributed to a harness at all. The marker is refreshed on every SessionStart and costs no network, so putting the harness on it would let CLI telemetry reason about harness per invocation — which is the grain we'd actually need to ask whether harness influences agentic CLI usage.

Two things worth saying up front:

• It'd need to stay schema: 1. The shipped CLI reader does a hard marker.schema !== 1 -> return null, so a bump would blank out vercel_plugin_active_session and vercel_plugin_version for everyone until they upgrade their CLI. An additive optional field is invisible to old readers.
• It isn't perfect: the marker is machine-global and last-writer-wins, so with two harnesses open at once a CLI invocation would get whichever started a session most recently, not necessarily the one that ran the command. Still much better than day-grain, but not exact.

The CLI side (reading it and emitting vercel_plugin_agent_harness) is a separate PR in vercel/vercel, so this would be shipping a producer slightly ahead of its consumer. Fine either way from our side — happy for the field to land here, or to pair the two and do both later if you'd rather not ship something unread.