Feature: supported cookie restore adapters for Codex and Claude desktop browsers

[solomonneas]

Feature: supported cookie restore adapters for Codex and Claude desktop browsers

Problem

Agent Pantry can restore cookies to a stopped Chromium profile or a running browser with a loopback CDP endpoint. The embedded browsers in the Codex and Claude desktop apps do not currently expose a supported CDP target to Agent Pantry.

This leaves two bad choices:

• write directly to a live Electron profile, which risks SQLite locking, cookie encryption mismatch, or profile corruption
• restore into a separate managed Chromium instance, which authenticates that browser but does not authenticate the desktop app's embedded browser

I hit this while restoring a GitHub session. Pantry restored 7 scoped cookies into a managed Chromium browser and verified all 7 through Storage.getCookies. The Codex embedded browser remained signed out because it had no reachable restore surface.

Proposed direction

Add explicit desktop-app restore adapters, for example:

agentpantry restore --sidecar ./sidecar.db \
  --domains github.com \
  --to desktop-app=codex \
  --verify

agentpantry restore --sidecar ./sidecar.db \
  --domains github.com \
  --to desktop-app=claude \
  --verify

The adapter should negotiate a supported runtime path instead of editing a live cookie database. Possible integrations include an app-provided local bridge, a narrowly scoped DevTools endpoint, or a native helper that asks the desktop app to import cookies through its own session API.

If no safe runtime path is available, Agent Pantry should refuse the live write and print exact stop-app and offline-restore instructions.

Safety requirements

• keep domain allowlists and deny-wins behavior
• never print cookie values
• detect whether the desktop app is running before any profile write
• refuse live SQLite mutation
• back up any offline profile database before changing it
• preserve the target app's own encryption and partition metadata
• verify expected versus present cookie names and counts through the target runtime
• fail closed when the app version or profile layout is unknown

Acceptance criteria

• Codex and Claude desktop targets are detected without hard-coding a user's home path
• a running app uses a supported runtime bridge or returns a clear refusal
• a stopped app can use a documented, backed-up offline restore only when encryption is compatible
• --dry-run reports the target, domains, cookie count, process state, and selected injection method
• --verify confirms the restored names and counts without exposing values
• Linux, macOS, and Windows behavior is documented separately

This would let Agent Pantry authenticate the browser surface an agent is actually controlling, while keeping the current rule that live browser databases are never opened or patched directly.

[solomonneas]

Merged the fail-closed discovery/refusal subset in #35. Codex and Claude targets now support metadata-only --dry-run inspection, while live writes and --verify refuse with recovery guidance. Issue #26 remains open because no supported external cookie import and read-back bridge is documented. Official OpenAI documentation checked on 2026-07-15 describes separate built-in browser state and sign-in/Chrome-extension paths, not a cookie import API: https://help.openai.com/en/articles/20001277-using-the-built-in-browser-in-the-chatgpt-desktop-app. Anthropic's official MCP, extension, and connector documentation likewise did not expose a supported cookie import/read-back contract. A full adapter remains blocked until such a bridge exists, or an offline path can prove process stop, schema/encryption compatibility, private backup, and read-back verification.