xtekky/gpt4free · error · RuntimeError

Failed to start shared Chrome on port {port}

Error message

Failed to start shared Chrome on port {port}

What it means

Raised in g4f/requests/cdp.py when the shared Chromium process was spawned on a dynamically chosen free port but never answered HTTP on that port within the startup window (the /json version probe loop failed). The code then terminates the child process and gives up with this RuntimeError, meaning Chrome launched but its CDP HTTP endpoint did not become reachable.

Source

Thrown at g4f/requests/cdp.py:289

        for _ in range(40):
            time.sleep(0.5)
            try:
                with urllib.request.urlopen(
                    f"http://{host}:{port}/json", timeout=1
                ) as response:
                    if response.status == 200:
                        _shared_browser_port = port
                        return _shared_browser_port
            except Exception:
                pass

        if _shared_browser_process:
            try:
                _shared_browser_process.terminate()
            except Exception:
                pass
            _shared_browser_process = None
        raise RuntimeError(f"Failed to start shared Chrome on port {port}")


class CDPSession:
    def __init__(
        self,
        port: Optional[int] = None,
        host: Optional[str] = None,
        user_data_dir: Optional[str] = None,
        headless: bool = True,
    ):
        if port is None:
            port = BrowserConfig.port
        if host is None:
            host = BrowserConfig.host
        if host is None:
            host = "127.0.0.1"
        self.port = port
        self.host = host

View on GitHub (pinned to 973504e177)

Solutions

1. Kill leftover chrome/chromium processes from previous runs, then retry.
2. If running in a container as root, ensure the browser is launched with --no-sandbox (adjust browser args used by g4f's launcher).
3. Retry the operation — the port race and slow-start cases are transient.
4. Check that the user_data_dir location is writable and on fast local disk.
5. Manually verify the browser can start: run the chrome binary with --remote-debugging-port=9222 and curl http://127.0.0.1:9222/json/version.

Example fix

# before: chrome fails to answer CDP in container as root
# after: ensure sandbox is disabled for containerized chrome
CHROMIUM_FLAGS="--no-sandbox --disable-gpu" python your_g4f_script.py

for attempt in range(2):
    try:
        session = CDPSession(); await session.start()
        break
    except RuntimeError as e:
        if "Failed to start shared Chrome" in str(e) and attempt == 0:
            await kill_stale_chrome()  # cleanup helper
            continue
        raise

When it happens

Trigger: Chrome starts extremely slowly (cold profile, heavy disk I/O) and misses the readiness deadline; Chrome crashes immediately on startup (bad flags, sandbox denial in containers, missing --no-sandbox in root containers); the chosen port got taken between bind-check and Chrome launch; zombie chrome processes exhausting resources.

Common situations: Running as root in Docker without --no-sandbox; SELinux/AppArmor blocking the child; slow network filesystems for the user_data_dir; leftover zombie Chrome processes from previous crashed runs.

Related errors

• CDP call {method} timed out after 30 seconds
• Syntax error in workspace module '{name}' ({source_path}):\n
• Failed to load workspace module '{name}' ({source_path}):\n{
• Relative imports are not allowed inside a .pa.py sandbox.
• '{name}' is not available in the restricted os shim.

AI-assisted analysis of xtekky/gpt4free@973504e177 (2026-08-14). Data as JSON: /api/errors/d4df3787c57c6b2e. Report an issue: GitHub.