close
Skip to content

Linux/WSL root user: /browse fails to start Chromium without CI=1 (missing --no-sandbox) #1364

@furkankoykiran

Description

@furkankoykiran

Summary

When running as root on Linux or WSL2, /browse fails to launch Chromium. The browser exits immediately and the server crashes. Setting CI=1 before invoking browse fixes it, but this is not documented and shouldn't be required.

Environment

  • OS: Linux (WSL2, kernel 6.6.87.2-microsoft-standard-WSL2)
  • User: root
  • gstack: latest (~/.claude/skills/gstack)
  • Playwright: bundled with gstack

Repro

# Running as root, without CI=1
B=~/.claude/skills/gstack/browse/dist/browse
$B goto https://example.com
# → [browse] FATAL: Chromium process crashed or was killed. Server exiting.

# Workaround: set CI=1 first
CI=1 $B goto https://example.com
# → Navigated to https://example.com (200)

Root Cause

browser-manager.ts already adds --no-sandbox when CI or CONTAINER env vars are set, because Chromium's sandbox requires unprivileged user namespaces that aren't available in those environments:

// browser-manager.ts:188
if (process.env.CI || process.env.CONTAINER) {
  launchArgs.push('--no-sandbox');
}

Running as root has the same constraint: Linux does not allow Chromium's sandbox to initialize for the root user. The check doesn't cover this case, so the sandbox fails silently and Chromium exits.

Fix

One additional condition in the same block:

const isRoot = typeof process.getuid === 'function' && process.getuid() === 0;
if (process.env.CI || process.env.CONTAINER || isRoot) {
  launchArgs.push('--no-sandbox');
}

The typeof process.getuid === 'function' guard keeps this safe on Windows where getuid is not defined.

Notes

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions