# eze-is/web-access: a Claude Code skill that adds CDP browser control to your agent > web-access is an Agent Skill that layers network strategy, Chrome and Edge CDP automation, and per-domain experience notes on top of the WebSearch and WebFetch tools your agent already has. It is for Claude Code and other SKILL.md-compatible agents that need to reach logged-in pages or dynamic sites, not for people who just want a search API. **eze-is/web-access** — 给 Claude Code 装上完整联网能力的 skill：三层通道调度 + 浏览器 CDP + 并行分治 - Repository: https://github.com/eze-is/web-access - Stars: 9,028 · Forks: 641 - Language: JavaScript - License: not declared - Published: 2026-09-21 · Updated: 2026-09-21 · Language: en - Canonical page: https://hysenlabs.com/projects/eze-is-web-access ## What web-access adds to a plain WebSearch and WebFetch setup The README frames the problem directly: an AI agent's built-in networking (WebSearch, WebFetch) lacks a scheduling strategy and browser automation. web-access is an Agent Skill that supplies three things on top of those tools: a networking strategy, CDP browser operation, and accumulated site experience. The README claims compatibility with any agent that supports SKILL.md, naming Claude Code, Cursor, Gemini CLI and Codex CLI. The practical gap it targets is the logged-in page. WebFetch retrieves a URL as an anonymous client. A support dashboard, an internal admin panel, or a creator backend will answer that request with a login wall or a redirect. web-access instead drives the browser you already use, so the session cookies and login state are simply there. The README states the CDP Proxy connects directly to the user's everyday browser (Chrome or Edge, Chromium-family), which it describes as naturally carrying login state, and supports dynamic pages, interactions and video frame capture. The second gap is choice. The skill lists five networking tools (WebSearch, WebFetch, curl, Jina and CDP) and describes selecting among them per scenario, in any combination. That is a policy decision the agent makes, not a fixed pipeline. ## How the CDP Proxy and the three click paths actually work The architecture is a local WebSocket proxy. According to the README, `scripts/cdp-proxy.mjs` connects to the browser over WebSocket using the same mechanism as `chrome://inspect` and `edge://inspect`, which means no command-line flags are needed to launch the browser. The proxy then exposes an HTTP API on localhost port 3456 that the agent calls. The API surface is small and page-scoped. Each call takes a `target` parameter identifying a tab. Endpoints include `/new` for a new tab, `/eval` for JavaScript execution, `/click` for a JS click, `/clickAt` for a real CDP mouse event, `/setFiles` for file upload, `/screenshot`, `/scroll`, `/close` and `/health`. The distinction between `/click` and `/clickAt` matters: a JavaScript click dispatches the event synthetically, while `/clickAt` sends an actual mouse event through CDP. Sites that check event trust will behave differently under the two. Tab lifecycle is managed by the proxy. It tracks tabs created through `/new` and closes idle ones after 15 minutes, with the stated goal of avoiding orphan tabs when an agent exits abnormally. The timeout is adjustable through the `CDP_TAB_IDLE_TIMEOUT` environment variable, in milliseconds. Two v2.5.4 changes are worth noting because they describe failure modes the project hit. The `/new` endpoint now creates `about:blank`, completes the CDP attach, and only then navigates, which the release notes say fixes a race where the browser's initial blank document was mistaken for the target page. And `/new` plus `/navigate` send the URL in a POST body as of v2.5.3, so an `&` inside a query string is no longer split incorrectly. ## Installing web-access and running a first CDP session The README gives four installation routes. The recommended one uses the open-source skills CLI, which the README says detects your agent environment and installs to the correct location. ```bash npx skills add eze-is/web-access ``` Claude Code users can install it as a plugin instead. The second command scopes it to the user rather than a project. ```bash claude plugin marketplace add https://github.com/eze-is/web-access claude plugin install web-access@web-access --scope user ``` A manual install is a plain clone into the skills directory. ```bash git clone https://github.com/eze-is/web-access ~/.claude/skills/web-access ``` For CDP mode there is a prerequisite the README states plainly: Node.js 22 or newer, plus a Chrome or Edge browser with remote debugging enabled. You open `chrome://inspect/#remote-debugging` or `edge://inspect/#remote-debugging` in that browser and check the box labeled Allow remote debugging for this browser instance. The README notes a browser restart may be required. Browser preference lives in `${CLAUDE_SKILL_DIR}/config.env`, created on first run from `config.env.template` and gitignored. Leaving the value empty makes the skill ask each time; setting it pins the browser. ```bash # empty = ask every launch; a value = pin that browser WEB_ACCESS_BROWSER=edge ``` Legal values are `chrome` and `edge`. A one-off override that does not touch the config file passes `--browser` to the dependency check script. To switch browsers while a proxy is already attached to the old one, the README says to kill the proxy first. ```bash pkill -f cdp-proxy.mjs && node "${CLAUDE_SKILL_DIR}/scripts/check-deps.mjs" ``` The README states the agent runs the dependency check automatically, so this is a manual fallback rather than a required step. Once the proxy is up, a first real call is a tab creation followed by an evaluation. Note that the URL goes in the request body, not as a query parameter. ```bash curl -s -X POST --data-raw 'https://example.com' http://localhost:3456/new curl -s -X POST "http://localhost:3456/eval?target=ID" -d 'document.title' ``` The first call returns a target identifier; you substitute it for `ID`. The second returns the page title, which confirms the proxy is attached to a live tab rather than a stale handle. ## find-url.mjs and the local bookmark and history search Added in v2.5.0 and extended to Edge in v2.5.2, `scripts/find-url.mjs` reads local Chrome and Edge bookmarks and history to locate a URL by keyword, time window, or visit frequency. The README's stated use cases are specific: a user mentions an internal system whose name returns nothing on the public web, a page the user visited before but cannot recall the address of, or a look at recently frequented sites. This is the most distinctive part of the project and the one with the clearest privacy implication. The skill is reading your browsing history. The README does not document what happens to that data beyond the local query, and it does not describe a redaction or filtering step. If you install this for someone else, or in a shared environment, that is the part to discuss first. The v2.5.2 notes say the search traverses Chrome and Edge by default and accepts `--browser ` to limit it to one. ## Where web-access is the wrong tool The README carries its own warning, and it is not a formality: operating social platforms through browser automation (it names Xiaohongshu) risks rate limiting or account bans, and the README strongly recommends using a secondary account. That is a real constraint on the headline use case. If your workflow depends on automating a platform account you care about, this skill is the wrong instrument regardless of how well the CDP layer works. The second limitation is the debugging toggle. The README describes deliberate behavior here: if the preferred or specified browser is not running or does not have the toggle enabled, the proxy hard-errors with explicit steps rather than silently connecting to a different browser, and it pins the browser id after the first successful connection to prevent drift mid-run. That is the right call for predictability, but it means the setup is brittle in a way a pure HTTP fetcher is not. Close the browser, forget the checkbox after an update, and the agent stops rather than degrading. Third, this is a Claude Code-shaped solution. The install paths, the `${CLAUDE_SKILL_DIR}` variable, and the plugin commands all assume that environment or one closely compatible with it. The README claims broader SKILL.md compatibility, but the documented configuration is Claude Code's. Fourth, there is no license file in the repository listing. The README, the top-level entries and the release notes do not state terms. Treat that as unresolved rather than permissive. ## How this differs from Jina, Playwright and the agent's own fetch The README positions Jina as one of the five selectable tools and, as of v2.3, explicitly encourages using it proactively where it saves tokens. That is the honest comparison: for a public page that renders server-side, Jina or WebFetch is cheaper and simpler than spinning up a browser. web-access earns its cost only when the page needs a session, JavaScript execution, or interaction. Against Playwright or Puppeteer, the difference is architectural rather than feature-level. Those tools launch their own browser instance under automation control. web-access attaches to the browser you are already using, which is why login state comes for free and why there is no profile to seed. The trade-off runs the other way too: you cannot isolate or reset the session, you inherit whatever extensions and state that browser carries, and you must leave remote debugging enabled on your daily driver. Against a plain `curl` in a shell tool, the difference is the same one that separates curl from a browser generally. curl gets the bytes the server returns for an anonymous request. CDP gets the DOM after scripts have run and after the user's cookies have been sent. The parallel sub-agent dispatch is a fourth axis. The README states that for multiple targets the skill dispatches sub-agents in parallel sharing one proxy, with tab-level isolation. That is a scheduling feature no single browser automation library gives you out of the box, though it also means concurrent tabs against the same site, which is exactly the pattern that triggers rate limiting. ## Maintenance, upgrades and the license question The last push to the default branch was on 2026-08-19, roughly a month before this writing, and the repository is not archived. Release history shows a steady cadence through 2026: v2.5.0, v2.5.1 and v2.5.2 all landed on 2026-05-15, and the README documents v2.5.3 and v2.5.4 changes on top of those. The v2.5.4 notes read like bug fixes from real use (a blank-tab race, a URL-encoding bug, a content-readiness contract), which suggests the project is being exercised rather than only extended. Upgrade cost is low by design. Installation through `npx skills add` or the Claude Code plugin marketplace means an update is a repeat of the install command, and the skill's own state is confined to `config.env` and the per-domain experience notes. The README does not document rollback, so if a new version breaks your workflow you should know which commit you cloned before you pull. The Node.js 22 requirement is the one upgrade dependency that can bite: an older runtime on the machine will fail the dependency check regardless of the skill version. On licensing, the repository listing shows no license file and the README states no terms. That is a gap, not a permission. Redistribution inside a product, or bundling the scripts into a commercial agent, is a question for the author. Using it locally for your own agent sessions is a different matter, but the terms are simply not stated in what the project publishes. ## Conclusion Adopt web-access if you already run Claude Code or another SKILL.md-compatible agent and your work involves pages that WebFetch cannot reach, such as internal systems behind a login or dynamic sites that need clicks. Do not adopt it if you only need plain search and fetch, or if you are unwilling to enable remote debugging in your daily browser, because the CDP path depends on that toggle. Before relying on it, verify three things: that Node.js on the machine is version 22 or newer, that chrome://inspect/#remote-debugging or edge://inspect/#remote-debugging accepts the remote debugging toggle on the browser you intend to use, and that the config.env file created on first run names the browser you actually want pinned. The repository carries no license file, so settle the licensing question with the author before shipping it inside a commercial product. ## FAQ ### What is web-access? It is an Agent Skill for Claude Code and other SKILL.md-compatible agents that adds networking strategy, CDP browser automation, and per-domain site experience on top of the built-in WebSearch and WebFetch tools. The README describes it as supplying three layers: a networking policy, CDP browser operation, and accumulated site knowledge. ### How do I install web-access? The README recommends the skills CLI with `npx skills add eze-is/web-access`, which detects your agent environment and installs to the right place. Claude Code users can instead add the marketplace and run `claude plugin install web-access@web-access --scope user`, or clone the repository into `~/.claude/skills/web-access` manually. ### Does web-access work with Chrome and Edge? Yes. The CDP Proxy connects to Chromium-family browsers, and Edge support arrived in v2.5.2 through the same auto-discovery mechanism. You enable remote debugging at `chrome://inspect/#remote-debugging` or `edge://inspect/#remote-debugging`, and the browser preference is pinned in `config.env` through `WEB_ACCESS_BROWSER`. ### What does web-access require before CDP mode works? The README states CDP mode needs Node.js 22 or newer and a Chrome or Edge browser with the Allow remote debugging for this browser instance checkbox enabled. If the specified browser is not running or the toggle is off, the proxy errors out with steps rather than connecting to a different browser. ### Is it safe to automate social platforms with web-access? The README warns that automating social platforms such as Xiaohongshu through the browser carries a risk of rate limiting or account bans, and strongly recommends using a secondary account. That warning sits in the usage notes rather than being buried in a changelog. ### Where does web-access store its browser preference? In `${CLAUDE_SKILL_DIR}/config.env`, which is created on first run from `config.env.template` and is gitignored. Setting `WEB_ACCESS_BROWSER` to `chrome` or `edge` pins the browser; leaving it empty makes the skill ask on each launch. ## Sources - [eze-is/web-access on GitHub](https://github.com/eze-is/web-access) - [Issues](https://github.com/eze-is/web-access/issues) - [README](https://github.com/eze-is/web-access/blob/main/README.md) - [Releases](https://github.com/eze-is/web-access/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/eze-is-web-access