PLUTO-51 ·
plutoProxy viewport tooling: chrome-devtools-mcp (CDP) for Pluto needs an auth path — Pluto is OAuth-only
- Ref
PLUTO-51(#923)- Project
pluto- Status
- backlog
- Priority
- low
- Type
- task
- Assigned
- —
- Created by
- wi-cli-venus
- Created
- 2026-06-12T04:21:26.011Z
- Updated
- 2026-06-12T04:21:26.011Z
Questions
No questions.
Event log
-
Open decision (route to Elazar). Fleet proxy-tooling move to official chrome-devtools-mcp (CDP): resize_page + Emulation.setDeviceMetricsOverride give a TRUE mobile viewport+DPR+coarse-pointer in an own Chrome instance, killing resize_window's OS-window width clamps + shared-instance contention. Venus is wiring it via its demo-password login. BLOCKER for Pluto: Pluto is Google-OAuth ONLY (login-client.tsx signInWithOAuth is the sole sign-in; no signInWithPassword in src/; no demo/password route; demo seeds get no auth.users row, so they can't OAuth either). A fresh own-Chrome CDP instance has NEITHER profile cookies NOR a password screen to auth through — so Pluto cannot just 'mcp add + demo-login' like Venus. Two paths, Elazar chooses: (a) BUILD a demo/password login path for proxy auth (real coder/db WI), or (b) attach chrome-devtools-mcp to the EXISTING authed Chrome via --remote-debugging-port (keeps OAuth profile cookies but reintroduces the shared instance; CDP device-metrics is per-page renderer-level, so far less contention than window-resize). NOT blocking the current PLUTO-40 baseline (captured on shared Chrome via Elazar manual F12 + proxy shot). Source: pm-venus-cc fleet recommendation 2026-06-12, Pluto OAuth-only correction by pm-pluto-cc.
-
Option-1 (own-instance + persistent --userDataDir) setup caveats from proxy-venus-cc-w (CLI-verified): (i) the MCP's DEFAULT profile is already persistent at $HOME/.cache/chrome-devtools-mcp/chrome-profile — do NOT pass --isolated and cookies persist. (ii) PROFILE LOCK: Chrome single-instances a user-data-dir, so the one-time human Google-OAuth must be 'log in, FULLY CLOSE Chrome, then MCP launches its own against that dir' — cannot share the dir concurrently. (iii) CHANNEL SUFFIX: default profile path carries a channel suffix under non-stable --channel, so pin the SAME channel for the human-login Chrome and the MCP-launch or they point at different dirs. Also fleet rule: use the tool for sizing, NOT resize_page (resize_page fails headless, upstream bug #294). All pending proxy-venus's post-relaunch hands-on confirmation (tool-name list, cookie persistence across MCP runs, mobile-DPR screenshot fidelity).
-
Fix prior note typo: the sizing tool is "emulate" — i.e. use the emulate tool for sizing, NOT resize_page (resize_page fails headless, bug #294).
-
Install-scope lesson (Elazar relay via pm-mars): proxy-venus installed chrome-devtools-mcp at session/local scope only -> did not persist, needs re-add every session. When proxy-pluto sets up, install at GLOBAL/USER scope from the start (claude mcp add --scope user ...) so it survives across sessions.
-
FIELD-PROVEN (proxy-venus hands-on, chrome-devtools-mcp live on whey): (1) 29 tools under mcp__chrome-devtools__* incl emulate, take_screenshot, navigate_page, new_page, evaluate_script, lighthouse_audit, performance traces. (2) Pre-authed --userDataDir persistence CONFIRMED — one human Google-OAuth survived a full mobile re-run + many navs, zero re-auth. BONUS: new_page accepts isolatedContext name = separate cookie jar per context; ran admin+alumno+titular logins concurrently in ONE browser, no cross-contamination -> multi-role capture with no logout churn / no extra profiles. (3) Mobile DPR exact via emulate viewport WxHxDPR[,mobile][,touch] (390x844x3->DPR3 crisp; 768x1024x2->DPR2); true pointer:coarse (matchMedia verified) render-confirms tap targets. GOTCHAS for runbook: (a) after changing emulated WIDTH do a FULL navigate (not reload) or innerWidth goes stale; (b) the mobile flag expands the ICB to fit overflow -> MASKS horizontal overflow (scrollWidth==innerWidth); for overflow audits use touch WITHOUT mobile. Status upgraded: design-verified -> field-proven on pixels.
-
Cross-project proof (pm-venus, first live CDP use): the tool caught a REAL 360px horizontal overflow on Venus /practicas/nueva that BOTH the className audit AND the emulate mobile-flag had MASKED. Implication for PLUTO-40: our mobile work to date (className-reading audits + F12 stopgap) shares this blind spot — when CDP lands on Pluto, RE-VERIFY the shipped Stage A + capture the baseline using emulate touch-WITHOUT-mobile to surface real overflow, do not trust the className pass alone. Fleet runbook now settled (emulate not resize_page; touch-no-mobile for overflow; full-navigate after width change). Host-wide user-scope install on whey is with nw-whey-cc.