[Security follow-up C-1] Move MCP pairing token from chrome.storage.local to .session

[hoainho]

🌟 Before claiming this issue

Two quick steps before you open a PR:

1. ⭐ Star the repository — low-friction signal that you'll follow through
2. 💬 Comment I'll take this (or similar) below — prevents two contributors racing on the same issue

Full policy: CONTRIBUTING.md → How to claim. If a claim is older than 7 days with no PR, you can reclaim it politely.

---

Tracks follow-up #1 from PR #17 security review. Blocked on mcp-server-v1 M3 (~Jul 28, 2026).

What

MCPPairingPanel currently stores the pairing token in chrome.storage.local. This is too long-lived — tokens persist across browser restarts and can be exfiltrated via any extension with storage permission. Use chrome.storage.session instead (cleared on browser restart, isolated per-tab).

Why

chrome.storage.local is persistent + readable by any extension with the storage permission. The MCP pairing token grants control of the debugger — same trust level as a session cookie. It should:

1. Survive panel navigation within the same browser session
2. Be cleared on browser restart
3. Not be readable by other extensions

chrome.storage.session satisfies all 3. It's been available since MV3 launched.

Acceptance criteria

• All token reads in src/panel/components/MCPPairingPanel.tsx go through chrome.storage.session (not chrome.storage.local)
• Migration path documented: existing chrome.storage.local entries for old keys are read once at panel load, copied to session, then deleted from local
• Add a unit test verifying the token does not appear in chrome.storage.local after the migration runs
• CHANGELOG entry noting the storage migration

Implementation hint

// In MCPPairingPanel.tsx
const TOKEN_KEY = 'mcp_pairing_token_v1';

async function saveToken(token: string) {
  await chrome.storage.session.set({ [TOKEN_KEY]: token });
}

async function readToken(): Promise<string | null> {
  const { [TOKEN_KEY]: token } = await chrome.storage.session.get(TOKEN_KEY);
  return token ?? null;
}

// One-time migration helper
async function migrateLegacyToken() {
  const { [TOKEN_KEY]: legacy } = await chrome.storage.local.get(TOKEN_KEY);
  if (legacy) {
    await chrome.storage.session.set({ [TOKEN_KEY]: legacy });
    await chrome.storage.local.remove(TOKEN_KEY);
  }
}

Context

• Related PR: feat: improve MCPPairingPanel error messages for invalid token/port (#7) #17 (MCPPairingPanel)
• Blocked by: mcp-server-v1 M3 milestone (this fix lands AFTER M3 ships the live MCP integration; until then, the token isn't actually used)
• Severity: Critical (security category C-1 in PR feat: improve MCPPairingPanel error messages for invalid token/port (#7) #17 review)

[iMindCap]

I'll take this

[hoainho]

Hi @iMindCap — thanks for picking this one up! Quick context to make sure we're aligned before you start:

Why this is security-sensitive

• chrome.storage.local is persistent across browser restarts and survives on the user's filesystem in plaintext
• .session is volatile: cleared on browser restart, never written to disk
• The pairing token is the only auth on the local MCP bridge — anyone with read access to the profile dir (or any XSS payload in the extension) can read it from localStorage and impersonate the user to the bridge
• Moving it to .session shrinks the attack window from "forever" to "the current browser session"

What I'd suggest for the PR

• Read the existing token storage helper in src/services/mcp-token-storage.ts (or wherever it lives — rg 'storage\.local' src/ to find all call sites)
• Swap the chrome.storage.local calls to chrome.storage.session (same API, different namespace)
• Add a migration: on startup, if a token exists in local, move it to session and clear local
• Add a test that confirms: (a) the token survives a tab close/reopen, (b) it does NOT survive a browser restart
• Update any related docs (docs/MCP_USAGE.md if it mentions persistence)

Review process for this PR

Since this touches the security surface, I'm going to review line-by-line and probably run a small threat-model pass. The Star Check workflow will pass for you (you're already a stargazer from #17), but I may ask for a 2nd reviewer since security PRs benefit from one extra set of eyes.

Optional but appreciated

If you find anything else sketchy while you're in the storage code (hardcoded secrets, overly-broad permissions in the manifest, anything in chrome.runtime.connect that trusts messages blindly), flag it in the PR description and I'll triage it as a separate issue.

No rush — security PRs are best when they're not rushed. Thanks again for taking this on. 🙏