DEV Community: tandt53

Check your message before Claude Code sees it

tandt53 — Sun, 15 Nov 2026 11:13:10 +0000

Copy a failing request from DevTools as curl, paste it into an AI coding agent and ask why it returns 401. The Authorization header goes to the model with the rest of the message. Nothing in Claude Code checks for it first.

So I added a check that does. It reads each message before it is sent and stops the ones that hold an API key.

Why it matters

Developers and testers paste things into AI coding agents all day: a failing curl command, a request copied from DevTools, twenty lines of a CI log, a config file that will not load. Any of those can carry an Authorization header, a session cookie or a key. Once it is in the message, it goes to the model with everything else, and a key that has left the machine has to be rotated.

I keep my Claude Code setup in an open-source repository, and this check is one of its hooks: a script Claude Code runs at a fixed point, here on every message before the model sees it.

What did not work

A rule in the agent's instructions. "Never handle secrets" is a rule for the agent. The key comes in with the paste, and by the time the agent reads any rule, the message has already been sent.

Masking the key before it is sent. My first idea was to find the key, replace it with ghp_… and send the rest. Claude Code runs a UserPromptSubmit hook on every message before the model sees it, but that hook can only block a message or let it through. It cannot rewrite it.

So the check had to be a hook, and a hook that blocks.

What worked: block only what is certainly a secret

A guard that blocks on a guess gets bypassed by habit. If every third message is stopped, people start typing the word that sends a message anyway, without reading the warning. So the hook has two levels:

Block: forms that are certainly secrets. GitHub tokens (ghp_, github_pat_ and the other kinds), Anthropic keys, AWS access key ids, private key blocks, JWTs, and a credential header or session cookie whose value looks real (more on that below).
Warn only: anything else that looks like a secret. When gitleaks, an open-source secret scanner, is installed, the message also goes through gitleaks stdin with a 2-second budget; on my machine it answers in about 20 ms. A gitleaks rule for one of the certain forms blocks. A generic rule such as generic-api-key only warns.

When it blocks, it says where and what, never the value. Here it stops a curl command in Claude Code:

The token in the prompt is a fake one, covered here anyway. The hook's own message shows only ghp_ct…5VYy.

The value is masked so the warning does not become one more place the key is written.

Headers: check the name or the value?

This was the real design question, because a pasted request is mostly headers.

Check only the header name, and every doc that says Authorization: Bearer $TOKEN is blocked.
Check only the value, and every commit hash and UUID looks like a key.

So the hook needs both: a credential header (Authorization, X-API-Key, X-Auth-Token and a few more) or a session cookie, and a value that looks real. "Looks real" is deliberately plain (comments added here):

def looks_real(value: str) -> bool:
    """A header value that is a credential, not a placeholder or a word."""
    value = value.strip()
    # short, a placeholder ($TOKEN, <your-key>, xxxx...), or too few distinct characters
    if len(value) < 16 or PLACEHOLDER.search(value) or len(set(value)) < 6:
        return False
    # a real credential mixes letters and digits
    return bool(re.search(r"[A-Za-z]", value) and re.search(r"\d", value))

$TOKEN, <your-key>, xxxxxxxxxxxxxxxx and process.env.API_KEY pass as placeholders. A Basic value is decoded first and blocks only when it holds user:password.

Two ways out exist on purpose. [secret-ok] at the start of a message sends it anyway, with a warning, for the day the "secret" is a test fixture the agent needs to see. CLAUDE_SKIP_SECRET_GUARD=1 turns the hook off. And if the hook itself crashes, the message goes through with a "could not scan" warning: a broken guard must never trap a message.

The result, and what it still cannot do

Now a message like the one at the top stops before it is sent. In a test with a fake GitHub token, the block took zero model turns, so nothing was spent.

The same test showed what a block does not do. The blocked message is not gone: its full text was still written once to the session transcript on disk. The guard keeps a secret from the model, not off the machine. A key that was pasted still needs rotating.

How I know the hook works:

18 tests, with fake keys built at run time, so the repository holds nothing a scanner would take for a key.
18 deliberate bugs. I broke a copy of the hook 18 ways and checked that a test failed each time. One break survived at first: removing the distinct-character rule failed no test, because the only dummy value in the tests, xxxx…, was already caught as a placeholder. A case with ab12ab12ab12ab12ab12 now covers it.

What I'd tell any team using AI coding agents

Guard the message, not the agent: the key comes in with the paste.
Block only certainties and warn on guesses, or the way out becomes muscle memory.
For headers, judge the name and the value together.
Know what a block does not do. The text can still sit on disk, so rotate a pasted key anyway.

The hook is one Python file, standard library only: hooks/secret_guard.py in my open-source Claude Code setup (Apache 2.0). docs/MECHANISMS.md lists what it enforces, what it does not, and how it was tested.

What is ChromeDriver?

tandt53 — Mon, 19 Jul 2021 02:01:11 +0000

Introduction

As in previous post, we discussed about Driver Service (like ChromeDriverService, FirefoxDriverService, etc.). It is to start and stop Driver Server before WebDriver initialized and after quit. So that, service needs to be configured driver executable file (via method useDriverExecutable(File file)). When working with selenium, you should have a driver executor for coresponding browser, like:

Chrome browser requires chromedriver.exe on Windows, or chromedrive on Linux and Mac.
Firefox browser requires geckodriver.exe on Windows, geckodriver on Linux and Mac.
Edge browser requires edgedriver.exe on Windows, edgedriver on Mac.

So, what are they responsible for? Why do we need it in Selenium web automation?

Driver Executor

Before we go further, I would remind the log when we start ChromeDriver. It will start a server on free port or on pre-defined port.

Starting ChromeDriver 91.0.4472.101 (...) on port 5353
ChromeDriver was started successfully.

First try

Browser drivers are executable, so we can try to run it in command line and check the result.

$ ./chromedriver 
Starting ChromeDriver 91.0.4472.101 (...) on port 9515
ChromeDriver was started successfully.

Wow, ChromeDriver server was started on port 9515. It was same with using ChromeDriverService in previous post.

From that, we can see that ChromeDriverService get driver executable file and it will start ChromeDriver server internally in selenium code. Then the other services(FirefoxDriverService, EdgeDriverService) do the same way to start browser Server.

Find more with --help

Now, we will explore chromedriver by run it with parameter --help to understand more options.

$ ./chromedriver --help
Usage: ./chromedriver [OPTIONS]

Options
  --port=PORT                     port to listen on
  --adb-port=PORT                 adb server port
  --log-path=FILE                 write server log to file instead of stderr, increases log level to INFO
  --log-level=LEVEL               set log level: ALL, DEBUG, INFO, WARNING, SEVERE, OFF
  --verbose                       log verbosely (equivalent to --log-level=ALL)
  --silent                        log nothing (equivalent to --log-level=OFF)
  --append-log                    append log file instead of rewriting
  --replayable                    (experimental) log verbosely and don't truncate long strings so that the log can be replayed.
  --version                       print the version number and exit
  --url-base                      base URL path prefix for commands, e.g. wd/url
  --readable-timestamp            add readable timestamps to log
  --enable-chrome-logs            show logs from the browser (overrides other logging options)
  --allowed-ips                   comma-separated allowlist of remote IP addresses which are allowed to connect to ChromeDriver

There are so many options available that driver server can start with.

For example:

To check chromedriver version, use --version

$ ./chromedriver --version
ChromeDriver 91.0.4472.101 (...)

To start ChromeDriver server with specific port (5353), use --port

 ./chromedriver --port=5353
Starting ChromeDriver 91.0.4472.101 (...) on port 5353
ChromeDriver was started successfully.

Selenium Driver Service

tandt53 — Mon, 19 Jul 2021 02:00:38 +0000

Introduction

In this post, I would like to introduce the different ways to initialize instance of WebDriver. It will help you understand more clearly about Selenium Architecture.

This post focuses on ChromeDriver constructors:

No argument constructor: public ChromeDriver()
Constructor with 1 parameter ChromeDriverService: public ChromeDriver(ChromeDriverService service)

No argument constructor

Firstly, I created a sample source code for initialize ChromeDriver instance:

String chromeDriverFilePath = "chromedriver"; // I downloaded chromedriver and put it in the root directory of project. On mac, the executor is chromedriver, but on Windows, using chromedriver.exe instead. 
System.setProperty("webdriver.chrome.driver", chromeDriverFilePath); 
WebDriver driver = new ChromeDriver();
driver.get("https://google.com.vn");

Above codes will start a selenium session and launch Google Chrome browser. Then it navigate to home page of google search. Let's run programm, we can see the log as follow:

Starting ChromeDriver 91.0.4472.101 (...) on port 8945
ChromeDriver was started successfully.

It shows that ChromeDriver was started successfully on port 8945. It means that there is some server was started on my machine on port 8945. But I did not set any thing like port or server options in our code. Where did they come from? Is ChromeDriver a server?
We will answer those question in next session.

Constructor with 1 parameter ChromeDriverService

Let's create an instance of ChromeDriverService via Builder and then create ChromeDriver with that.

String chromeDriverFilePath = "chromedriver";
ChromeDriverService.Builder builder = new ChromeDriverService.Builder();
builder.usingAnyFreePort();
builder.usingDriverExecutable(new File(chromeDriverFilePath));
ChromeDriverService service = builder.build();
WebDriver driver = new ChromeDriver(service);
driver.get("https://google.com.vn");

The code shows that service will be built after set 2 information for builder (usingAnyFreePort, and usingDriverExecutable is a file of chromedriver). Then that instance is passed into constructor of ChromeDriver then navigate to Google Search. Now run the program to see the behavior nothing different but log:

Starting ChromeDriver 91.0.4472.101 (...) on port 29284
ChromeDriver was started successfully.

Let's change a little bit in our code:

ChromeDriverService.Builder builder = new ChromeDriverService.Builder();
builder.usingPort(5353); // change 
builder.usingDriverExecutable(new File("chromedriver"));
ChromeDriverService service = builder.build();
service.start(); // new line 
WebDriver driver = new ChromeDriver(service);
driver.get("https://google.com.vn");
driver.quit();  // new line
service.stop(); // new line

There are 4 lines updated:

line 2: we changed builder using any free port by a specific port number (5353).
line 5: service is started before create instance of ChromeDriver.
line 7: driver is quit after navigate to Google search.
line 8: service is stopped after driver quit. Now run program once again and check the console log:

Starting ChromeDriver 91.0.4472.101 (...) on port 5353
ChromeDriver was started successfully.

This time, ChromeDriver server was started on port 5353, as we set in builder of service. Now we understand that ChromeDriverService will be incharged of initiate ChromeDriver server using configured informations (port and driver executable file). And we can control those configuration (starting server in different port, or using different version of chromedriver) as we want.

Summary

From above code, we see that out test scripts will start an driver server (ChromeDriver server, GeckoDriver server, etc.) whenever we call new instance of WebDriver for corresponding browser. Then, every command (click, sendKeys, getText, etc.) will be transformed from script (selenium client) to that server to interact with browser, and finaly get result.

In }}">next post, I will present about driver executable file (chromedriver.exe, geckodriver.exe) for more details.