feat: add cookie management tools - #3
Open
steffen-heil-secforge wants to merge 2 commits into
Open
steffen-heil-secforge wants to merge 2 commits into
steffen-heil-secforge wants to merge 2 commits into
Conversation
… MCP server
Lets a password be filled into a page without ever passing the plaintext
to a tool, so it never enters the conversation transcript. fill,
fill_form, type_text and evaluate_script substitute {{secret:NAME}} with
the contents of <data-dir>/secrets/NAME in this MCP server, immediately
before the input is dispatched to the browser.
A secret is consumed (deleted) once the call succeeds; ":keep" retains it
and ":raw" preserves a trailing newline.
{{script:NAME}} does the same for <data-dir>/scripts/NAME, so the same
JavaScript can be run repeatedly without the caller writing it out in
every call. The code is still sent to the browser each time; only the
caller is spared repeating it. A script takes no modifiers: it is never
consumed and always used exactly as stored.
Resolution runs in exactly two passes, scripts then secrets, so a script
may carry a secret but substituted content is never rescanned: scripts do
not nest and a secret value is never interpreted as a placeholder.
Both directories live under this server's own per-OS data directory,
keyed off "chrome-devtools-mcp" rather than any MCP client, and can be
relocated with CHROME_DEVTOOLS_MCP_SECRETS_DIR and
CHROME_DEVTOOLS_MCP_SCRIPTS_DIR. The per-OS resolution telemetry already
used moves to utils/paths.ts so both share it.
References are basename-only so they cannot escape their directory, and
resolved values are kept out of every response: type_text echoes the
unresolved text, and fill errors report the placeholder rather than the
substituted value.
Adds a secret-handling skill covering staging by reference, login and
2FA flows, script reuse, and the request-body caveat.
steffen-heil-secforge
force-pushed
the
feature/cookie-tools
branch
3 times, most recently
from
September 13, 2026 18:29
00064fe to
d85d10a
Compare
Adds get_cookies, set_cookie and clear_cookies, covering the inspect, edit and delete cases raised in ChromeDevTools#408. Cookies in the browser profile are not fully reachable with the existing tools: cookieStore and document.cookie cannot see or modify HttpOnly cookies, and the network tools only show cookies for requests that happened to be captured. These tools go through CDP, so they cover HttpOnly cookies and domains the page never requested. Cookie values are kept out of the conversation in both directions. get_cookies writes them to a JSON file and reports only each cookie's name, domain, path, expiry and security flags, so enumerating a profile does not dump live session tokens into the transcript. set_cookie does not echo the value back, and resolves {{secret:NAME}} placeholders, so a session token never has to be passed to the tool as literal text. clear_cookies deletes cookies matching a name and/or domain, passing each cookie's partition key so partitioned (CHIPS) cookies are not silently left behind. Clearing every cookie signs the user out of every site, so it refuses to do that implicitly: an explicit "all: true" is required when no filter is given. The domain filter matches on domain-label boundaries, so "example.com" covers "www.example.com" but never "notexample.com" or "example.com.evil.test". A substring match would have let clear_cookies delete cookies the caller never asked for. All three act on the default browser context, which the cookie-debugging skill is updated to say, along with the HttpOnly cases that are now reachable.
steffen-heil-secforge
force-pushed
the
feature/cookie-tools
branch
from
September 14, 2026 06:42
d85d10a to
81ae2ab
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Important
Depends on #2. Stacked on it:
set_cookieresolves{{secret:NAME}}placeholders introduced there, so a session-token cookie value never has to be passed as literal text.Adds
get_cookies,set_cookieandclear_cookies, covering the inspect / edit / delete cases raised in ChromeDevTools#408.Why a tool rather than the skill
The
cookie-debuggingskill documents what is reachable today, and is explicit that two things are not:HttpOnlycookies are invisible tocookieStoreanddocument.cookie. The skill's workaround is to find them in theCookieheader of a captured request.That leaves real gaps. ChromeDevTools#408 asked directly "How important is it to support HttpOnly cookies?", and the answer in the thread was "Would want this... Or else, we'll still have to use playwright for HttpOnly for extraction." These tools go through CDP (
Storage.getCookies,Network.setCookie,Network.deleteCookies), so both cases are covered.Tools
get_cookiesEnumerates every cookie in the browser's default context, optionally filtered by domain.
Cookie values are written to a JSON file and never returned inline. The response reports only each cookie's name, domain, path, expiry and security flags. This matters: on a normal profile this tool finds hundreds of cookies, including live session tokens for every site the user is signed in to, and returning those inline would put them into the conversation transcript (and any log of it) wholesale.
filePathis therefore required rather than optional.set_cookieSets a cookie;
urlordomainis required so the browser knows where it applies. Supportspath,expires,httpOnly,secureandsameSite. The value is not echoed back in the response. A rejection by the browser is reported with the likely causes (domain mismatch, orsameSite: "None"withoutsecure).clear_cookiesDeletes cookies matching
nameand/ordomain.Clearing everything signs the user out of every site, so the tool refuses to do it implicitly: with no filter given it errors and asks for an explicit
all: true. This is deliberate — a model reaching for "clear cookies" to reset one site should not silently destroy every session in the profile.Testing
tests/tools/cookies.test.tscovers: writing values to the file while keeping them out of the response, the domain filter,set_cookierejecting a call with neitherurlnordomain,set_cookieactually setting a cookie without echoing its value,clear_cookiesrefusing an unfiltered wipe, andclear_cookiesdeleting only the matching cookie.These require a browser, so they have not been run in my environment — they follow the existing patterns in that directory and I would appreciate CI confirming them.
npm run check-format,tsc --noEmitand the tool registration (62 tools, all three present with the expected schemas) were all verified locally.