@sema-agent/connector-browser 0.2.0 → 0.2.2

package/CHANGELOG.md

@@ -4,6 +4,25 @@ All notable changes to this package are documented here. Released sections are
 frozen: once a version is published its section is never edited again; new text
 goes into the next version's section.
 
+## 0.2.2 (2026-10-25)
+
+### Changed
+
+- Re-pinned to `@sema-agent/connectors` 0.9.0, so `sema-connector-browser` gains the shared CLI kit's `unmount` and
+  `list` subcommands (CN-065), `mount`'s duals: `unmount` removes only the entry `mount` wrote for this connector
+  (no entry is idempotent; an entry under the name that is not `mount`'s own shape is refused and left alone) and
+  `list` prints the mounted connectors' names and configuration directories, never a credential. Nothing in this
+  package's own code changed. An entry a person extended with `toolAxes` is not listed and is refused by `unmount`
+  (`KNOWN-LIMITS.md`, KL-32).
+
+## 0.2.1 (2026-10-24)
+
+### Changed
+
+- Ships its own copy of `docs/KNOWN-LIMITS.md` as `KNOWN-LIMITS.md` inside the package (CN-063: its README's
+  mention of `docs/KNOWN-LIMITS.md` pointed at a repository path that did not resolve once installed), and is
+  re-pinned to `@sema-agent/connectors` 0.8.1 at release (CN-062, CN-064).
+
 ## 0.2.0 (2026-10-23)
 
 ### Added

package/KNOWN-LIMITS.md

@@ -0,0 +1,39 @@
+# Known limits
+
+Accepted, low-severity limits that are not scheduled for a fix. Each entry states when it would stop
+being acceptable. An entry must not describe a second source of truth, a documented exception to a
+contract, or a long-lived transitional path: those are defects and get a ticket instead.
+
+| ID | Symptom | Why it is not fixed | Trigger | Upgrade criterion |
+|---|---|---|---|---|
+| KL-01 | A standalone catalog entry names its configuration directory with an absolute `--config-dir`. After the directory is moved, or when the `mcp` domain is exported in a bundle to another machine, the entry still names the old path: the launcher finds no secrets there and reports `unauthorized`, and `mount` (and with it the seed) refuses the stale entry as a conflict until it is removed by hand. | The engine starts stdio connectors with a minimal environment, so the entry must carry the directory (CN-028); an absolute path is machine-local by nature, like the installed connector package the entry also depends on. The seed (CN-009) never overwrites an entry, so it does not repair one. | Moving the configuration directory; importing a bundle that carries connector entries. | The CLI wrapper (CN-012) rewriting entries on import, or an engine that hands its configuration directory to stdio connectors. |
+| KL-02 | The end-to-end gate pins `@sema-agent/server` 7.136.0 word for word in `test/negctl/CN-006.json`: the four helper invocations the server starts outside the egress probe (`ps`, two `git` commands and `/bin/bash`, each with its exact arguments) and the variables `MODEL_ID`, `MODEL_API_KEY` and `APPROVAL_GRANT` it needs for a local run. A server release that changes any of them turns the gate red until a person has reviewed the new invocations or variables and updated the fixture. The per-tool axes gate (CN-013) pins wording the same way in `test/negctl/CN-013.json`: the start of the line with which a local run of `@sema-agent/server` 7.136.0 reports a call it refused for want of a person, and the reason that line gives for each of the two refusals it expects (the engine's wording, `@sema-agent/core` 7.55.0). | The server documents neither its helper processes nor the minimal environment of a local run as a stable contract, nor the wording of a refused call (the engine gives no code per reason); the fixtures record what the pinned releases do, and a reviewed change is what the gates are for. | A new version of the `@sema-agent/server` development dependency. | The server documents these helpers and variables as a stable contract, or publishes a machine-readable minimal environment that the gate can read instead of the fixture; for the refusal wording, a refusal the server reports with a code per reason. |
+| KL-03 | On the hosted http face, `GET /status` answers `503` until a client has opened a session and the connector has answered `initialize`; a health probe on a fresh launcher sees an error although the launcher is fine (the compose healthcheck probes for the `401` instead). | The status lists the tools the caller sees, which only a running connector can tell; a `200` before that would carry an invented empty list, and the contract has no way to say "unknown". | Reading `/status` on a hosted launcher before any session, or after the session ended. | A `connector-status-v1` change that can state the tools as unknown, or a hosted launcher that starts its connector at boot (M2, with the token vault). |
+| KL-04 | A connector that takes none of its waiting input for 10 seconds is ended as "stalled" (`connector.internal` on every pending call; exit 5 on stdio), also when it is merely busy: a client that keeps sending more than the pipe holds while one tool runs synchronously for over 10 seconds loses its pending calls. A reader taking at least about 1 KiB per 10 seconds is not affected. | The launcher cannot tell "stopped reading" from "busy", and without the bound a connector that stops reading leaves the launcher and itself hanging when upstream only closes its pipe (CN-025). | A connector that blocks for more than 10 seconds while more input than the pipe buffer waits for it. | A connector protocol signal for "busy", or a measured need for a longer bound from a real connector (M1). |
+| KL-05 | A connector directory whose `.auth.lock` was left behind (a process killed while holding it, a power loss during `auth`) stops every launch of that connector: the launcher waits 5 seconds, exits 2 and names the lock; `auth` and `status` wait and refuse the same way, until someone removes the lock file by hand. | The lock is never guessed stale (a live holder could be slow), the same rule as the mount lock; a liveness check by pid would be wrong across machines and containers. | A crash or kill while a write or a launch snapshot holds the lock. | A lock that carries a lease the holder renews, or an operator command that removes a lock after checking its holder. |
+| KL-06 | When a connector has secret values, the launcher holds back the last bytes of the connector's stderr until it knows they do not begin a secret, so a receipt line the launcher writes meanwhile can land in the middle of a connector's log line (the line resumes after the receipt). Programs splitting at the documented line breaks still read every receipt whole; only a person reading the log sees the split. | Withholding needs the lookahead, and receipts are written when a call settles. | A connector writing a log line slowly while a call settles. | A reader that needs receipts apart from the connector's log: a sink of their own (CN-035 kept them on the launcher's stderr, with a bound). |
+| KL-07 | `mount` and `auth` report success once the new file is written whole, synced and renamed into place, but the directory is not synced afterwards and the file sync is the ordinary `fsync` (not the full flush some file systems need): a power loss right after a reported success can leave the old `config.d/mcp.json` or token file, or on some file systems an empty one. | The whole-write rule (CN-042) is about never putting a file cut short in place; crash durability is a separate property with a platform-specific cost. | A power loss or kernel crash within moments of a successful `mount` or `auth`. | A measured need from a deployment, or a platform rule for directory sync and full flush. |
+| KL-08 | Storing a secret handle writes its metadata file before its value file, so a value write that fails leaves the new metadata (for example a new `expiresAt`) next to the old value; the connector CLI reports the failure with exit 1 and `auth` has to be run again. | The order keeps a secret from being marked as not a secret halfway through; the pair is written whole again by the next `auth`. | A write failure between the two files of one handle. | A per-handle write that lands both files or neither. |
+| KL-09 | A seed whose marker write fails (a full disk, a file size limit) exits 1 with `write_failed`, but the entries it mounted stay, unrecorded: a person who removes one of them before the next successful seed sees the next seed mount it again. | Undoing a mount would need a second writer that removes entries from `config.d/mcp.json`, outside `mount`; the next seed that can write the marker finds the entries and records them as present. | A marker write that fails, then an entry removed before a seed that succeeds. | A remove operation through `mount` (the CLI wrapper, CN-012) that the seed can undo with, or a measured case of a failing marker write. |
+| KL-10 | A write that fails before anything is in place can leave an empty directory behind: `mount` creates `config.d` before it writes the catalog file, and the secrets backend creates `connectors/<name>` before it writes a handle, so a refused `mount` on a fresh directory leaves an empty `config.d`, a failed `put` an empty `connectors/<name>`, and an `install` refused for an archive that does not match the lock an empty `connectors/<name>/bin` (0700). | An empty directory changes nothing a reader sees (no catalog entry, no handle), and removing it would need a guess that nothing else is about to use it. | A first `mount` or `put` whose write fails (a full disk, a file size limit). | A reader that treats the empty directory as a state of its own. |
+| KL-11 | The GitHub connector hands its personal access token to github-mcp-server in the variable `GITHUB_PERSONAL_ACCESS_TOKEN`: while github-mcp-server runs, a process of the same user (or root) that reads other processes' environments reads the token, and so does a crash report or core dump that records the environment. The Gitea connector hands gitea-mcp only the path of its 0600 copy, so its token is only ever in a file (which the same user can read too). | github-mcp-server 2.0.2 takes a personal access token from that variable only: it has no file or descriptor input for it. An argument would be readable by every process, so the variable is the narrowest way in. | Running the GitHub connector where other processes of the same user are not trusted. | github-mcp-server gains a file or descriptor input for the token (the connector then hands it the per-launch copy's path, as for Gitea). |
+| KL-12 | With a token that looks like a classic personal access token (it starts with `ghp_`), github-mcp-server 2.0.2 sends `HEAD https://api.github.com/` (with a stored host, `HEAD <host>/api/v3/`) with the token every time it starts, before any tool is called, to read the token's scopes: every start of the GitHub connector, `sema-connector-github status` included, contacts GitHub. With a token that starts like a fine-grained one (`github_pat_`) or with neither prefix it connects nowhere until a tool is called; other kinds of token (such as `gho_`) were not measured. | It is github-mcp-server's own start-up (it hides the tools a classic token cannot use) and no option of it turns the request off; the destination is the GitHub API the token belongs to, and the gate fails on any other. | Starting the GitHub connector with a classic personal access token. | github-mcp-server gains an option to skip the scope request, or a deployment needs a start without network (a fine-grained token avoids it today). |
+| KL-13 | A standalone connector that needs no credentials never runs: with no secret handle the launcher parks the session (see "Parked session" in `ARCHITECTURE.md`), so such a connector shows `unauthorized`, lists no tools and has no `auth` to run; storing any secret handle for it starts it. | The state has one judgement (a secret handle is present or not) and no second fact such as a declaration by the connector that it needs none; the private stub and the gates' planted connectors store a handle first. | A connector package that takes no credential, mounted in a standalone directory. | A connector of this repository that genuinely needs no credential (the browser connector of M1 keeps its login state as a handle instead). |
+| KL-14 | `statusCommand` and `seed` find the launcher and the connector packages through this package's own `package.json` (`import.meta.url`), so a copy of `@sema-agent/connectors` inlined into another program's bundle cannot run them (`mount`, `unmount`, `listMounted` and their CLI wrappers are unaffected: none of them resolves its own package); the package is consumed installed. | A bundled copy has no package directory to resolve from, and a second way of finding the launcher would be a second source. | A command-line tool that bundles its dependencies and calls `statusCommand` or `seed`. | A consumer that must bundle; then the launcher path and the resolution root become explicit inputs of those two functions. |
+| KL-23 | A standalone browser connector that is mounted without a `tools.json` grants every tool, `browser_run_code_unsafe` and `browser_evaluate` among them (CN-054 gives the operator the allow list; nothing writes one by default). | A default policy would be a second source of what the operator decides, and the shared layer does not know one connector's tools from another's. | The browser connector mounted with no policy file. | A connector package that ships a default `tools.json` the operator can override, as one rule for every connector. |
+| KL-24 | The GitHub connector authenticates with a personal access token only; github-mcp-server's own OAuth login never runs, because the parked session keeps the upstream from starting without a token (CN-052). | An OAuth flow needs a person at a browser and a place to keep the result; the connector's `auth` and the handle store are that place, and the flow is designed when a deployment needs it rather than guessed now. | A deployment that cannot issue personal access tokens. | A deployment that needs OAuth: then `auth` gains an OAuth form that stores the result as the token handle (the GitHub connector's next minor). |
+| KL-17 | The standalone browser connector has no egress policy: the browser opens whatever URL a tool call names, follows redirects and loads what pages load. playwright-mcp's `--allowed-origins` is not a security boundary (playwright-mcp says so) and is not used. | Browsing what the engine asks for is the connector's purpose; an egress policy belongs to the hosted container (M2, M3), enforced outside the browser. | Any browsing. | The hosted deployment's egress proxy (M3), whose only input is the engine's host floor entries, or a standalone policy with an enforcement point outside the browser. |
+| KL-18 | On Linux, Chromium's sandbox needs unprivileged user namespaces (or a setuid sandbox helper): in a container without them Chromium does not start and every page tool fails. The browser connector always passes `--sandbox` (playwright-mcp leaves the sandbox off on Linux for Chrome for Testing otherwise) and never `--no-sandbox`. | Without the sandbox a compromised renderer acts as the user; the container's profile (user namespaces, seccomp) is the deployment's to provide, not the connector's to work around. | The browser connector on Linux where user namespaces are disabled, as in many container runtimes by default. | The hosted deployment declares a container profile with user namespaces (M2), or a measured deployment that cannot provide them. |
+| KL-19 | Chrome for Testing 155 contacts Google on its own when it starts, although Playwright passes switches meant to keep it quiet: the browser gate's proxied run names `accounts.google.com`, `update.googleapis.com`, `www.google.com` and `android.clients.google.com` (port 443), and past a proxy Chromium also connects a UDP socket to `[2001:4860:4860::8888]:443`; without a proxy it goes through the system's proxy settings or directly. | The requests come from Chromium components no option of playwright-mcp turns off, and the connector passes Chromium no switch of its own; the gate contains them and fails on a host outside google.com and googleapis.com. | Every start of the browser. | A playwright-mcp option or a Chromium switch that stops them, an egress policy (KL-17), or a host outside those domains in the gate's reading. |
+| KL-20 | Chrome for Testing is pinned for `darwin-arm64` and `linux-x64` only: on another platform `install` of the browser connector refuses (`pins no playwright-mcp build for <platform>`). | Chrome for Testing publishes no Linux arm64 build, and the macOS x64 build has not been fetched and checked. | Installing the browser connector on another platform. | A request for another platform, with its archive downloaded and its sha256 checked. |
+| KL-21 | While the browser runs, playwright-mcp publishes it for other Playwright tools of the same user: a socket under `/tmp/pw-<hash>/browser/` (the system's temporary directory: the launcher passes no `TMPDIR` to the connector) and an entry in Playwright's registry, which since CN-040 lies in the program's home in the connector's directory (`<CONNECTOR_DIR>/home/Library/Caches/ms-playwright/b` on macOS, `<CONNECTOR_DIR>/home/.cache/ms-playwright/b` on Linux) rather than in the user's home. A process of the same user can find the socket and attach to the browser and its session there, and the entry stays behind when the browser does not close normally. | It is playwright-mcp's own behaviour, with no option to turn it off; a process of the same user can read the stored login state in the configuration directory anyway. | The browser connector where other processes of the same user are not trusted. | playwright-mcp gains an option not to publish the browser, or the hosted form (one container per session). |
+| KL-22 | When playwright-mcp is killed with `SIGKILL` before it has closed the browser, Chromium (a process group of its own) keeps running, unreachable, until it is killed by hand (measured still running 86 seconds later). The launcher's teardown sends `SIGKILL` two steps (2 s) after the end of input; playwright-mcp closes the browser on the end of its input (measured 0.16 to 0.33 s) or on `SIGTERM` (0.16 s on a quiet machine, 2.2 and 5.4 s in two gate runs on a loaded one), so a close that outlasts the two steps is possible under load. | Playwright starts Chromium in a process group of its own and nothing outside playwright-mcp knows its pid; the teardown steps are one rule for every connector (CN-025). | playwright-mcp killed with `SIGKILL` (out of memory, or a close that outlasts the teardown steps). | A browser left running in normal use, or a way for the connector to learn Chromium's process group. |
+| KL-25 | What a pinned upstream program keeps under its home, `<CONNECTOR_DIR>/home` (CN-040), is neither scanned nor redacted, and nothing removes it: gitea-mcp's log (its tool errors, which can name URLs and user names of the Gitea server), Playwright's registry of running browsers, and whatever caches a program keeps. The gates measured no dummy token in gitea-mcp's log after a tool call. | The files are the program's own and stay inside the 0700 connector directory, outside the user's home; the launcher keeps secret values out of what it forwards (the message path and stderr), and scanning a program's private files would be a second redaction path with no rule for what it may change. | An upstream program that writes a value it was given (a token, a host's credentials) into a file under its home. | A token measured in a file under a program's home, or an upstream option to turn its file log off. |
+| KL-26 | With the browser connector's export of the login state on (CN-055), a save stores everything the browser holds at that moment: the session's login, and also the cookies and local storage any page visited in the session set for its own site, including a login a page forced on another site (a login cross-site request forgery). The next launch starts from all of it, as a browser with a profile on disk would. | The state is playwright-mcp's own `browser_storage_state` of the whole browser context; choosing which origins to keep would be a second rule over a state the connector does not otherwise interpret, and the person turned the export on to keep what the session holds. | A save after browsing pages that are not trusted, with the export on. | A request to keep only named sites, or a measured case of a stored state carrying a page's forced login. |
+| KL-27 | A request line the launcher cannot read on stdio (over 4 MiB, a batch, a repeated key, an id that is neither a string nor a number) is answered with `id` null and `connector.request_unreadable` (CN-030), so an MCP client cannot match the answer to the request it sent: it sees an error it cannot place and waits for that request until its own timeout. Over the hosted http face the same refusal is the answer to its own http request (`400` or `413`), so nothing waits there. | Nothing of a line the launcher cannot read is read, its id included: a batch has no single id, a line over 4 MiB is never parsed, and an object with a repeated key may carry an id that parsers read differently, so reading an id out of it would judge a message the launcher has just refused to judge. JSON-RPC answers a request whose id it cannot detect with id null too. | A tool call whose arguments make its line longer than 4 MiB; a batch, a repeated key or an id of another type, which the MCP SDK clients do not send. | A client measured waiting on such a request in normal use, or one reading of the id that every parser shares agreed for these lines. |
+| KL-28 | A host can stop delivering the sandbox reports of one executable while the sandbox goes on refusing (seen on 2026-10-22: for hours no report of a refused node connection, while bash was reported as before). The connector gates then cannot see what node processes try past the probe, the planted upstreams included: the attempts are refused (the gates' control processes read `EPERM`) but not observed, and the last line of each gate says so ("the host delivered no sandbox reports for node, so attempts by unprobed processes (...) were blocked but not observed"). Delivery is shown only for the executables of the gates' control processes (bash and node); for gitea-mcp, github-mcp-server and Chrome for Testing the gates read the reports that come and cannot tell a host that drops them. | The reports are the host's to deliver, and nothing in sandbox-exec or the system log asks for them; what keeps a connection from leaving is the refusal, which the control still proves on every run. Failing the gate would turn it red for something this repository cannot change. | A host that stops delivering the reports of an executable. | A check that needs the reports themselves, not the refusal, comes to depend on them (github-mcp-server's name lookups are read from its reports), or the reports of a pinned program are seen missing: then that program gets a control process of its own. |
+| KL-29 | On the hosted http face a session that has had no request of its own for 10 minutes is released (CN-033): a client that holds a session, sends nothing for longer and then sends a request gets `404` for its session id and has to `initialize` again (MCP Streamable HTTP answers that `404` with a new session). A request in flight for longer than 10 minutes is not affected, and neither is its session while it waits. The 10 minutes are fixed: no deployment setting changes them. | The face opens no stream, so the launcher has no sign that a client is still there other than its requests; a session held until `DELETE` kept every other client at `409` until the launcher restarted, and one fixed time is one rule for every deployment. | A client idle for more than 10 minutes within one session. | A deployment measuring clients that are idle for longer in normal use, or the hosted session model of M2 (a session per client, or a stream that shows the client is there). |
+| KL-30 | There is no media connector, and the media service's external contract list (its HTTP and console faces, and the refusal shape of its MCP tool face: an `isError: true` result whose text starts with `<code>: <text>`) is not consumed by anything in this repository. | The media connector is M4 work behind the hosted container (M2); until it is designed there is nothing to pin, and a ticket that only waits is not a debt. | Any media use case. | The M4 media connector design, which reads the service's list and takes its refusal shape into the contract review. |
+| KL-31 | A connector that changes its tool list at runtime is not re-read by the engine: the launcher forwards `notifications/tools/list_changed`, but the engine does not consume it, so a tool declared after the handshake is refused until the session is reconnected. | The consumer side is the engine's, and the engine has closed its ticket as a known limit; there is nothing in this repository to pin until the engine reads the notification. | A connector whose tool list changes while a session is open. | The engine consuming `tools/list_changed`; this repository then adds the positive control (the pointer ticket CN-018 is closed into this entry). |
+| KL-32 | After a person adds `toolAxes` (or any other member) to a connector's standalone entry in `config.d/mcp.json`, `mount` of that connector refuses with a conflict (exit 1) and leaves the entry as written, and a seed that has not yet recorded the connector reports it as `conflict` (exit 1). `list` no longer shows the connector as mounted (the entry is no longer exactly what `mount` would write) and `unmount` refuses to remove it (`unexpected_shape`, never deleting what it did not write): recovering the standalone catalog's own reading of the connector means removing the extended entry from `config.d/mcp.json` by hand. | `mount` compares the whole entry and never overwrites one; telling the deployment's members from its own would need a list of the catalog's members, which are the settings schema's (this repository defines no catalog types). | Running `mount`, `list` or `unmount`, or a first seed, after editing the entry by hand. | The CLI wrapper (CN-012) editing entries through `mount`, or a reader of the entry's deployment members exported by the settings schema. |
+| KL-33 | One entry anywhere in `config.d/mcp.json`'s `servers` that is nested too deep to compare (deeper than the shape comparison follows) makes `mount` and `unmount` of every connector in that configuration directory refuse with `unexpected_shape`, and `listMounted` refuse the whole call, not only the one entry: the post-write verification compares the whole list, so one unreadable entry means no write can be verified. | Answering for the other entries while one cannot be read would report a list shorter than the truth, or write a file whose verification is partial; refusing the whole call keeps the file and the lock exactly as they were. The limit on width (an entry with very many members) and the cost of `listMounted` on a very long list are not measured and not pinned. | A hand-edited `config.d/mcp.json` with a deeply nested entry (a seed or `mount` never writes one). | A reader of the catalog that reports per-entry problems instead of refusing the whole file (a settings-schema export of the entry shape would make that reading one source). |

package/README.md

@@ -27,8 +27,8 @@ sema-connector-browser status
 On Linux the connector keeps Chromium's own sandbox on (`--sandbox`, never `--no-sandbox`), which needs user
 namespaces: in a container that does not allow them (Docker's default seccomp profile, for one) the first
 `browser_navigate` answers `Chromium sandboxing failed!` and nothing is browsed. Run the connector on a host or in a
-container that allows user namespaces (KL-18 in the repository's `docs/KNOWN-LIMITS.md`); the connector never turns
-the sandbox off.
+container that allows user namespaces (KL-18; see `KNOWN-LIMITS.md`, shipped with this package and, in the
+repository, `docs/KNOWN-LIMITS.md`); the connector never turns the sandbox off.
 
 Then restart the engine. To start from a login instead of a clean profile, save a Playwright storage state (for example
 with Playwright's `context.storageState({ path })` after logging in) to a file only you can read, and give `auth` its path:
@@ -105,6 +105,10 @@ connector and answers itself (see "Parked session" in [`ARCHITECTURE.md`](../ARC
 25 tools of playwright-mcp (26 with the export on, see "Exporting the login state"); reading them starts playwright-mcp
 but not the browser, which starts at the first tool that needs a page.
 
+`unmount` removes that entry again and `list` prints the connectors mounted in the configuration directory, through the
+shared `unmount` and `listMounted` (`@sema-agent/connectors` 0.9.0, CN-065); an entry under this connector's name that
+is not exactly what `mount` writes is refused and left alone, and never listed (`KNOWN-LIMITS.md`, KL-32).
+
 ## What runs
 
 With no arguments, `sema-connector-browser` is the connector process the launcher starts. It refuses to start (exit 1,

package/bin/sema-connector-browser.mjs

@@ -1,7 +1,7 @@
 #!/usr/bin/env node
 // sema-connector-browser (CN-027): the browser connector's executable. With no arguments it runs the pinned Playwright
-// MCP server as an MCP stdio server; a first argument dispatches install, auth, mount and status
-// (docs/CONNECTORS/browser.md). Implementation: src/cli.ts, built to dist/cli.js.
+// MCP server as an MCP stdio server; a first argument dispatches install, auth, mount, unmount, status
+// and list (docs/CONNECTORS/browser.md). Implementation: src/cli.ts, built to dist/cli.js.
 import { main } from '../dist/cli.js'
 
 process.exitCode = await main(process.argv.slice(2), process.env)

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sema-agent/connector-browser",
-  "version": "0.2.0",
+  "version": "0.2.2",
   "description": "Browser connector: runs the pinned Playwright MCP server and a pinned Chrome for Testing behind the sema-connector launcher, in an isolated, headless session whose login state is a secret handle.",
   "license": "Apache-2.0",
   "type": "module",
@@ -16,13 +16,14 @@
     "CHANGELOG.md",
     "binaries.lock.json",
     "NOTICE",
-    "README.md"
+    "README.md",
+    "KNOWN-LIMITS.md"
   ],
   "scripts": {
     "build": "tsc -p tsconfig.json"
   },
   "dependencies": {
-    "@sema-agent/connectors": "0.8.0",
+    "@sema-agent/connectors": "0.9.0",
     "@sema-agent/connectors-contract": "0.2.0"
   },
   "engines": {