-
Notifications
You must be signed in to change notification settings - Fork 29
Description
Summary
When using headed mode, users may want to control the browser window size and position using X11 tools like xdotool and xwininfo. Currently, there's no way to get the Chrome process PID directly from chrome-ws or the MCP tool, requiring workarounds like searching by window title.
Requested Interface
# Simple PID output
./chrome-ws pid
780375
# Or richer info command
./chrome-ws info
{"pid": 780375, "mode": "headed", "profile": "superpowers-chrome", "port": 9222}This would enable direct integration with X11 tools:
CHROME_PID=$(./chrome-ws pid)
WID=$(xdotool search --pid "$CHROME_PID" | head -1)
xdotool windowsize "$WID" 800 600Use Case
In headed mode, JavaScript's window.resizeTo() does not actually resize the window manager window - it only affects the internal viewport. To properly resize/position the browser window, users need X11 tools:
# These require the window ID or PID
xdotool windowsize $WID 800 600
xdotool windowmove $WID 100 100
xwininfo -id $WID # Check window propertiesTo get the window ID, the most reliable method is via PID:
# If we had the PID, we could easily get window info
WID=$(xdotool search --pid $CHROME_PID | head -1)Current Behavior
The Chrome PID is already tracked internally in chrome-ws-lib.js:
Line 1265 - PID is logged to stderr on startup:
console.error(`Chrome started in ${mode} mode (PID: ${proc.pid}, profile: ${chromeProfileName})`);Lines 1283-1285 - PID is used for killing Chrome:
if (chromeProcess && chromeProcess.pid) {
process.kill(chromeProcess.pid, 'SIGTERM');
}However, it's not exposed via the module exports or any CLI/MCP action.
Proposed Solution
Option A: Add getChromePid() to chrome-ws-lib.js exports
// Add function near other lifecycle functions
function getChromePid() {
return chromeProcess ? chromeProcess.pid : null;
}
// Add to module.exports (around line 2030)
module.exports = {
// ... existing exports
// Chrome lifecycle
startChrome,
killChrome,
getChromePid, // NEW
showBrowser,
hideBrowser,
getBrowserMode,
// ... rest
}Option B: Add CLI command
In chrome-ws, add a pid or info command:
./chrome-ws pid
# Output: 780375
./chrome-ws info
# Output: {"pid": 780375, "mode": "headed", "profile": "superpowers-chrome", "port": 9222}Option C: Add MCP action
In mcp/src/index.ts, add a GET_CHROME_PID or extend BROWSER_MODE action:
// Extend browser_mode to include PID
case BrowserAction.BROWSER_MODE: {
const mode = chromeLib.getBrowserMode();
const pid = chromeLib.getChromePid();
return JSON.stringify({ ...mode, pid });
}Benefits
- Direct integration with X11 window management tools
- Scripting support - Combine MCP for content automation with xdotool for window control
- No title-based searching - Avoids ambiguity when multiple Chromium windows exist
- Consistent - PID is already tracked, just needs to be exposed
Workaround (Current)
Until this is implemented, users can find the window via title search:
# Search by page title (requires unique title)
WID=$(xdotool search --name "Wikipedia - Chromium" | head -1)
PID=$(xdotool getwindowpid "$WID")
# Or search by Chrome's user-data-dir pattern
PID=$(pgrep -f "remote-debugging-port=9222" | head -1)
WID=$(xdotool search --pid "$PID" | head -1)
# Or parse stderr when starting Chrome
./chrome-ws start 2>&1 | grep -oP 'PID: \K\d+'These workarounds are fragile because:
- Title search fails if multiple windows have similar titles
- pgrep pattern may match other Chrome instances
- stderr parsing only works at startup time
Additional Context
- This was discovered while testing window resizing - JavaScript
window.resizeTo()doesn't work at the window manager level - The MCP
browser_modeaction already returns mode and profile info - adding PID would be natural - Would enable powerful automation combining content control (MCP) with window management (xdotool)
Environment
- Plugin: superpowers-chrome
- Platform: Linux (X11)
- Use case: Headed mode with multi-monitor setup
🤖 Generated with Claude Code