Problem
When running the chrome-cdp skill in a sandboxed environment (common in enterprise deployments, containerized setups, and cloud-hosted AI coding tools like Claude Code on the web), all page-level commands fail because the per-tab daemon cannot create its Unix domain socket.
The daemon uses Unix sockets at /tmp/cdp-<targetId>.sock for IPC between the CLI and the persistent CDP connection. Sandboxed environments block the socket() / bind() syscalls for AF_UNIX at the kernel level, producing:
Error: listen EPERM: operation not permitted /tmp/cdp-XXXXXXXXXX.sock
This means none of the following commands work in a sandboxed environment:
snap / shot / html — cannot take page snapshots or screenshotseval — cannot evaluate JavaScript on the pagenav / click / type — cannot navigate or interact with page elementsnet — cannot capture network requestsloadall — cannot inject lazy-loaded content
Only list partially works (when it falls through to a direct WebSocket connection), but any command that requires a daemon — which is all per-tab commands — fails immediately.
Impact
This effectively makes the skill unusable in any sandboxed environment. Since sandboxing is increasingly common in enterprise settings (Docker containers, cloud workspaces, managed developer environments), this is a significant limitation that blocks a large class of users from using the skill at all.
Root Cause
The daemon in cdp.mjs calls server.listen(socketPath) to create a Unix domain socket. In sandboxed environments, the kernel security policy denies the creation of Unix sockets entirely — this is not a file permission issue and cannot be worked around with chmod or path changes.
Solution
PR #18 fixes this by replacing Unix domain sockets with TCP on 127.0.0.1 using OS-assigned ephemeral ports. Daemon discovery switches from socket files to JSON port files ($TMPDIR/cdp-<id>.port). Since TCP ports lack the filesystem-level access control of Unix sockets, an auth token handshake is added to prevent unauthorized local connections.
Problem
When running the chrome-cdp skill in a sandboxed environment (common in enterprise deployments, containerized setups, and cloud-hosted AI coding tools like Claude Code on the web), all page-level commands fail because the per-tab daemon cannot create its Unix domain socket.
The daemon uses Unix sockets at
/tmp/cdp-<targetId>.sockfor IPC between the CLI and the persistent CDP connection. Sandboxed environments block thesocket()/bind()syscalls forAF_UNIXat the kernel level, producing:Error: listen EPERM: operation not permitted /tmp/cdp-XXXXXXXXXX.sock
This means none of the following commands work in a sandboxed environment:
snap/shot/html— cannot take page snapshots or screenshotseval— cannot evaluate JavaScript on the pagenav/click/type— cannot navigate or interact with page elementsnet— cannot capture network requestsloadall— cannot inject lazy-loaded contentOnly
listpartially works (when it falls through to a direct WebSocket connection), but any command that requires a daemon — which is all per-tab commands — fails immediately.Impact
This effectively makes the skill unusable in any sandboxed environment. Since sandboxing is increasingly common in enterprise settings (Docker containers, cloud workspaces, managed developer environments), this is a significant limitation that blocks a large class of users from using the skill at all.
Root Cause
The daemon in
cdp.mjscallsserver.listen(socketPath)to create a Unix domain socket. In sandboxed environments, the kernel security policy denies the creation of Unix sockets entirely — this is not a file permission issue and cannot be worked around withchmodor path changes.Solution
PR #18 fixes this by replacing Unix domain sockets with TCP on
127.0.0.1using OS-assigned ephemeral ports. Daemon discovery switches from socket files to JSON port files ($TMPDIR/cdp-<id>.port). Since TCP ports lack the filesystem-level access control of Unix sockets, an auth token handshake is added to prevent unauthorized local connections.