CloakBrowser Pro 148.0.7778.215.3 crashes with SIGSEGV on Linux Docker

[maithanhtrung123]

Description:

I am using CloakBrowser Pro Chromium `148.0.7778.215.3` and it crashes immediately on my Linux Docker runtime.

The crash happens when calling `launchPersistentContext()`. It also happens with a minimal `about:blank` test and no proxy, so this does not appear to be proxy-related.

Expected:
`launchPersistentContext()` should start Chromium and create the persistent context successfully.

Actual:
Chromium launches, then immediately exits with `SIGSEGV`.

CloakBrowser version:
- npm wrapper: `cloakbrowser@0.4.4`
- Pro binary: `148.0.7778.215.3`

Wrapper:
JavaScript / Node.js

Environment:
- Linux VPS
- Docker: yes
- Node: v22.23.1 inside container
- Platform: linux-x64
- DISPLAY: Xvfb on `:99`
- Windows fonts mounted at `/usr/share/fonts/windows`
- Widevine mounted, but not required to reproduce

Launch options:

```js
import { launchPersistentContext, binaryInfo } from "cloakbrowser";

console.log(await binaryInfo());

const ctx = await launchPersistentContext({
  userDataDir: `/tmp/cb-smoke-${Date.now()}`,
  headless: false,
  geoip: false,
  args: [
    "--fingerprint=12345",
    "--fingerprint-noise=false",
  ],
});

const page = ctx.pages()[0] || await ctx.newPage();
await page.goto("about:blank");
console.log("launch-ok");
await ctx.close();

Tested with a different IP or proxy?
Yes. It fails with no proxy at all.

Works outside Docker / on host machine?
Not tested outside Docker.

Steps to reproduce:

1. Install wrapper:

   npm install cloakbrowser@0.4.4

2. Use Pro binary 148.0.7778.215.3:

   CLOAKBROWSER_VERSION=148.0.7778.215.3

3. Run the minimal script above inside Docker.

4. Chromium crashes immediately.

Error output:

binaryInfo {
  version: '148.0.7778.215.3',
  bundledVersion: '146.0.7680.177.5',
  tier: 'pro',
  platform: 'linux-x64',
  binaryPath: '/root/.cloakbrowser/chromium-148.0.7778.215.3-pro/chrome',
  installed: true,
  cacheDir: '/root/.cloakbrowser/chromium-148.0.7778.215.3-pro'
}

browserType.launchPersistentContext: Target page, context or browser has been closed
Browser logs:

<launching> /root/.cloakbrowser/chromium-148.0.7778.215.3-pro/chrome ...
<launched> pid=56

Call log:
  - <launched> pid=56
  - [pid=56] <gracefully close start>
  - [pid=56] <kill>
  - [pid=56] <will force kill>
  - [pid=56] exception while trying to kill process: Error: kill ESRCH
  - [pid=56] <process did exit: exitCode=null, signal=SIGSEGV>
  - [pid=56] starting temporary directories cleanup
  - [pid=56] finished temporary directories cleanup

Additional notes:

I tested rollback with the new wrapper version pinning:

CLOAKBROWSER_VERSION=148.0.7778.215.2

The exact same script works with 148.0.7778.215.2:

rollback-launch-ok

So the regression appears specific to the Linux x64 Pro binary 148.0.7778.215.3.

[Cloak-HQ]

Thanks for the detailed report and the thorough rollback testing — that really helps isolate the regression to the 215.3 binary.

I tried to reproduce the SIGSEGV with the exact same setup you described:

• Wrapper: cloakbrowser@0.4.4 (npm)
• Pro binary: 148.0.7778.215.3 (downloaded from the server, SHA verified)
• Node: v22.23.1
• Platform: linux-x64
• Xvfb: :99
• Flags: --fingerprint=12345 --fingerprint-noise=false
• Method: launchPersistentContext() with headless: false, geoip: false, about:blank
• Widevine: also tested with CLOAKBROWSER_FETCH_WIDEVINE=1

I tested this on two different Docker environments (our test container and the official cloakhq/cloakbrowser:latest image), and the launch succeeded in every run — no crash, no SIGSEGV.

Since the same binary works here, the crash is likely triggered by something specific to your Docker environment. Could you share:

1. Your Dockerfile or base image (e.g. ubuntu:24.04, debian:12, something else)?
2. cat /proc/cpuinfo output from inside the container?
3. ldd /root/.cloakbrowser/chromium-148.0.7778.215.3-pro/chrome — any missing libraries?
4. docker info | grep seccomp — are you using a non-default seccomp profile?

If you'd prefer not to post these details publicly, feel free to send them to support@cloakbrowser.dev and we'll continue troubleshooting there.

Let us know what you find!

— CloakHQ

[EucalyZ]

Additional findings (Pro 148.x + SOCKS / Docker)

We hit a related but slightly different failure mode on Linux Docker + Xvfb, and did a controlled version pin comparison as suggested here for 215.2 vs newer Pro builds.

Environment

Item	Value
OS / runtime	Linux x64, Docker, Xvfb :99
Wrapper	cloakbrowser==0.4.7 (also saw update notice for 0.4.10)
Pro binaries tested	148.0.7778.215.2-pro, 148.0.7778.215.5-pro (pinned via CLOAKBROWSER_BINARY_PATH)
Free control	146.0.7680.177.5
Launch API	launch_persistent_context_async(...)
Proxy	Residential SOCKS5 with auth: socks5://user:pass@host:port (1024proxy-style sticky SID)
License	Valid Pro solo plan at time of test (/api/license/validate → valid: true)

Summary of results

Binary	No proxy	Local unauthenticated SOCKS (127.0.0.1, near-zero latency)	Residential SOCKS5 (auth, slower dial)
Pro 148.0.7778.215.2	PASS	PASS	PASS (~3s to example.com)
Pro 148.0.7778.215.5	PASS	PASS	FAIL
Free 146.0.7680.177.5	PASS	PASS	often OK (varies with exit quality)

Takeaway aligned with this issue: pinning back to 148.0.7778.215.2 restores working Pro + SOCKS in our setup, while 215.5 fails on the same residential SOCKS path.

Failure mode on 215.5 + residential SOCKS (with a valid license) was usually:

TimeoutError: Page.goto: Timeout 25000ms exceeded
Call log:
  - navigating to "https://example.com/", waiting until "commit"

With an invalid/expired license earlier (same 215.5 binary forced via path), we more often saw hard close:

TargetClosedError: Page.goto: Target page, context or browser has been closed

So TargetClosed / process death is still in the same family as the report here; the exact Playwright surface error can vary (close vs hang) depending on license state and proxy latency.

Latency isolation (local SOCKS we control)

We also ran a local no-auth SOCKS5 server and injected artificial handshake delay (not residential-specific):

Local SOCKS handshake delay	Free	Pro 215.5 (and generally Pro path)
~0 ms (fast dial + reply)	PASS	PASS
≥ ~200 ms before SOCKS success reply	PASS	FAIL (TargetClosedError)
Local HTTP CONNECT, delay ≥ ~0.6s before 200	PASS	FAIL
Local SOCKS chaining to residential SOCKS (slow dial ~1–2s)	PASS	FAIL on 215.5

Interpretation:

1. SOCKS URL format is not wrong — Pro works on fast local socks5://127.0.0.1:port and on 215.2 + residential SOCKS.
2. Pro is very sensitive to proxy tunnel / handshake latency; free is not.
3. Residential SOCKS (slow CONNECT/dial) reliably trips the bad path on 215.5, while 215.2 succeeds on the same class of proxy.
4. This is not the silent “SOCKS auth falls back to direct” failure mode from SOCKS5 with username/password auth silently falls back to direct connection #157 (we verified exit IP via HTTP through SOCKS; free still loads via proxy).

Related public reports: #386 (SOCKS stalls in CloakBrowser while stock Chrome is fine), #157 (SOCKS auth edge cases; different symptoms).

Minimal reproduction (version pin)

# 1) Valid Pro key required to download Pro archives
export CLOAKBROWSER_LICENSE_KEY=cb_xxx
export SOCKS5_PROXY_URL='socks5://USER:PASS@residential-host:port'

# 2) Download pinned Pro builds (API)
for VER in 148.0.7778.215.2 148.0.7778.215.5; do
  curl -sSL \
    -H "Authorization: Bearer $CLOAKBROWSER_LICENSE_KEY" \
    -H "X-Platform: linux-x64" \
    "https://cloakbrowser.dev/api/download/${VER}" \
    -o "pro-${VER}.tar.gz"
  mkdir -p "chromium-${VER}-pro"
  tar -xzf "pro-${VER}.tar.gz" -C "chromium-${VER}-pro"
done

# 3) Minimal Docker runtime: python:3.13-slim + Chromium deps + Xvfb + cloakbrowser==0.4.7
#    Mount both extracted pro dirs, then:

# compare_pro_versions.py (minimal)
import asyncio, os, tempfile
from pathlib import Path
from cloakbrowser import launch_persistent_context_async

async def once(label: str, binary: str, proxy: str | None):
    os.environ["CLOAKBROWSER_BINARY_PATH"] = binary
    key = os.environ["CLOAKBROWSER_LICENSE_KEY"]
    profile = Path(tempfile.mkdtemp(prefix="cb-"))
    kw = dict(
        user_data_dir=str(profile),
        headless=False,          # under Xvfb
        geoip=False,
        humanize=False,
        timezone="America/Guayaquil",
        locale="es-EC",
        args=["--fingerprint=42", "--disable-dev-shm-usage"],
        viewport=None,
        license_key=key,
        proxy=proxy,             # None | socks5://...
    )
    ctx = await launch_persistent_context_async(**kw)
    try:
        page = ctx.pages[0] if ctx.pages else await ctx.new_page()
        resp = await page.goto("https://example.com/", wait_until="commit", timeout=25_000)
        print(label, "OK", getattr(resp, "status", None), await page.title())
    finally:
        await ctx.close()

async def main():
    proxy = os.environ["SOCKS5_PROXY_URL"]
    await once("215.2+socks", "/path/chromium-148.0.7778.215.2-pro/chrome", proxy)
    await once("215.5+socks", "/path/chromium-148.0.7778.215.5-pro/chrome", proxy)
    await once("215.5+noproxy", "/path/chromium-148.0.7778.215.5-pro/chrome", None)

asyncio.run(main())

Expected (our lab):

• 215.2+socks → OK 200 Example Domain
• 215.5+socks → FAIL (timeout and/or TargetClosedError)
• 215.5+noproxy → OK

Optional latency probe (local SOCKS):

1. Run a tiny no-auth SOCKS5 on 127.0.0.1.
2. Delay ≥200ms between client CONNECT and SOCKS success reply.
3. Pro 215.5 → TargetClosedError; Free / Pro with 0ms delay → OK.

Notes

• We used binary path pin so wrapper license auto-fallback to free cannot mask Pro behavior (invalid license previously made “Pro” tests silently use free).
• We did not need socks5h:// for Chrome (that path produced ERR_NO_SUPPORTED_PROXIES in an earlier probe); string form socks5://user:pass@host:port matches docs / native SOCKS path (--proxy-server=...).
• Happy to run extra builds (e.g. 215.3 only, or 0.4.10 wrapper) if useful.

Thanks for documenting the 215.2 rollback in this issue — it was the right fix direction for our Pro + residential SOCKS case as well.

[EucalyZ]

Follow-up: full Docker image setup (minimal lab)

The previous comment sketched the Python pin test but omitted a copy-pasteable Docker image. Here is the self-contained lab image we used (no app code — only CloakBrowser + Chromium deps + Xvfb).

Dockerfile

# Minimal CloakBrowser A/B lab (Linux x64 + Xvfb)
ARG CLOAKBROWSER_PIP=cloakbrowser==0.4.7
FROM python:3.13-slim-bookworm

ENV DEBIAN_FRONTEND=noninteractive \
    DISPLAY=:99 \
    PYTHONUNBUFFERED=1 \
    PIP_DISABLE_PIP_VERSION_CHECK=1

RUN apt-get update && apt-get install -y --no-install-recommends \
    ca-certificates curl procps tini \
    libnss3 libnspr4 libatk1.0-0 libatk-bridge2.0-0 libcups2 \
    libdbus-1-3 libdrm2 libatspi2.0-0 libxkbcommon0 \
    libxcomposite1 libxdamage1 libxfixes3 libxrandr2 libgbm1 \
    libpango-1.0-0 libcairo2 libasound2 libx11-xcb1 libx11-6 \
    libxcb1 libxext6 libxshmfence1 libxss1 libxtst6 \
    libgtk-3-0 libpangocairo-1.0-0 libgdk-pixbuf-2.0-0 \
    libglib2.0-0 libfontconfig1 fonts-liberation \
    xvfb \
    && rm -rf /var/lib/apt/lists/*

ARG CLOAKBROWSER_PIP
RUN pip install --no-cache-dir "${CLOAKBROWSER_PIP}" "httpx[socks]" "requests[socks]"

WORKDIR /lab
COPY entrypoint.sh run_compare.py /lab/
RUN chmod +x /lab/entrypoint.sh

ENTRYPOINT ["/usr/bin/tini", "--", "/lab/entrypoint.sh"]
CMD ["python3", "/lab/run_compare.py"]

entrypoint.sh

#!/bin/sh
set -e
Xvfb :99 -screen 0 1366x768x24 -nolisten tcp -ac +extension GLX +render -noreset &
export DISPLAY=:99
sleep 0.5
exec "$@"

Build

docker build -t cloak-min-repro:local .

Optional wrapper pin:

docker build --build-arg CLOAKBROWSER_PIP=cloakbrowser==0.4.10 -t cloak-min-repro:0.4.10 .

Download Pro binaries on the host (valid license required)

export CLOAKBROWSER_LICENSE_KEY=cb_xxx   # valid Pro key
mkdir -p /tmp/cloak-version-lab && cd /tmp/cloak-version-lab

for VER in 148.0.7778.215.2 148.0.7778.215.5; do
  curl -sSL \
    -H "Authorization: Bearer ${CLOAKBROWSER_LICENSE_KEY}" \
    -H "X-Platform: linux-x64" \
    "https://cloakbrowser.dev/api/download/${VER}" \
    -o "pro-${VER}.tar.gz"
  mkdir -p "chromium-${VER}-pro"
  tar -xzf "pro-${VER}.tar.gz" -C "chromium-${VER}-pro"
  # archive extracts chrome at top level of that dir
  test -x "chromium-${VER}-pro/chrome"
done

run_compare.py (pin binary path so free fallback cannot mask Pro)

#!/usr/bin/env python3
import asyncio, os, tempfile
from pathlib import Path
from cloakbrowser import launch_persistent_context_async

async def once(label: str, binary: str, proxy: str | None) -> None:
    os.environ["CLOAKBROWSER_BINARY_PATH"] = binary
    key = os.environ["CLOAKBROWSER_LICENSE_KEY"]
    profile = Path(tempfile.mkdtemp(prefix="cb-"))
    kw = dict(
        user_data_dir=str(profile),
        headless=False,  # headed under Xvfb
        geoip=False,
        humanize=False,
        timezone="UTC",
        locale="en-US",
        args=["--fingerprint=42", "--disable-dev-shm-usage"],
        viewport=None,
        license_key=key,
    )
    if proxy:
        kw["proxy"] = proxy
    ctx = await launch_persistent_context_async(**kw)
    try:
        page = ctx.pages[0] if ctx.pages else await ctx.new_page()
        resp = await page.goto(
            "https://example.com/", wait_until="commit", timeout=25_000
        )
        print(label, "OK", getattr(resp, "status", None), await page.title())
    except Exception as e:
        print(label, "FAIL", type(e).__name__, str(e).splitlines()[0][:200])
    finally:
        try:
            await ctx.close()
        except Exception:
            pass

async def main() -> None:
    proxy = os.environ.get("SOCKS5_PROXY_URL")  # socks5://user:pass@host:port
    await once(
        "215.2+socks",
        "/pro/chromium-148.0.7778.215.2-pro/chrome",
        proxy,
    )
    await once(
        "215.5+socks",
        "/pro/chromium-148.0.7778.215.5-pro/chrome",
        proxy,
    )
    await once(
        "215.5+noproxy",
        "/pro/chromium-148.0.7778.215.5-pro/chrome",
        None,
    )

if __name__ == "__main__":
    asyncio.run(main())

Run container

export CLOAKBROWSER_LICENSE_KEY=cb_xxx
export SOCKS5_PROXY_URL='socks5://USER:PASS@residential-host:port'

docker run --rm \
  -e CLOAKBROWSER_LICENSE_KEY \
  -e SOCKS5_PROXY_URL \
  -e CLOAKBROWSER_SUPPRESS_FONT_WARNING=1 \
  -v /tmp/cloak-version-lab/chromium-148.0.7778.215.2-pro:/pro/chromium-148.0.7778.215.2-pro:ro \
  -v /tmp/cloak-version-lab/chromium-148.0.7778.215.5-pro:/pro/chromium-148.0.7778.215.5-pro:ro \
  -v "$PWD/run_compare.py:/lab/run_compare.py:ro" \
  cloak-min-repro:local \
  python3 /lab/run_compare.py

Expected (our lab, residential SOCKS5)

215.2+socks    OK 200 Example Domain
215.5+socks    FAIL  (TimeoutError and/or TargetClosedError)
215.5+noproxy  OK 200 Example Domain

Why mount binaries instead of downloading inside the container?

Pro archives require a valid license (403 Invalid or expired license without one). Pinning extracted trees with CLOAKBROWSER_BINARY_PATH also prevents the wrapper from silently selecting free Chromium when validation fails, which otherwise masks Pro-only regressions.

Happy to adjust the Dockerfile (fonts, cloakbrowser version, headless-only) if that helps your triage of #402.

[Cloak-HQ]

Update: we can't reproduce this on the current Pro line (v150, 150.0.7871.114.3).

We retested on linux-x64 in Docker with Xvfb, matching the original minimal case:

• launchPersistentContext() → about:blank, headed, no proxy → launches cleanly, no SIGSEGV
• launchPersistentContext() + an authenticated HTTP proxy + geoip + a real navigation → also clean, page loads through the proxy exit

The 215.3 line where this first showed up has been superseded several builds over. Could you both update to the latest binary and retest?

• pip install -U cloakbrowser / npm update cloakbrowser with your license key pulls v150 — you can drop any CLOAKBROWSER_BINARY_PATH pin so it takes the current stable.

@EucalyZ — one thing we didn't cover: your report used a SOCKS5-with-auth proxy on the persistent-context path, which is a slightly different code path than the HTTP proxy we tested. If v150 still crashes for you, can you confirm whether it happens with SOCKS5 specifically vs. no proxy / HTTP proxy? That'll tell us if there's a SOCKS5-specific issue still live. Thanks.