DEV Community: RedCapra

The secret was correct. The first byte wasn't.

RedCapra — Sun, 20 Sep 2026 09:53:07 +0000

Our deploy tool pushed a fresh API token to production. It reported success. The token was correct. Every request then failed with this:

Cannot convert argument to a ByteString because the character at
index 7 has a value of 65279 which is greater than 255.

Character 65279 is U+FEFF, a byte-order mark. Index 7 is the first character after Bearer.

Something had prefixed a BOM onto our token, between reading it out of the vault and storing it at the platform. The value was right. The bytes were not.

Why we could not just look

The obvious move is to open the dashboard and read the variable. You cannot. The variable is marked Sensitive, which means it is write-only: the dashboard shows nothing, the CLI shows nothing, and the API returns the row with the value omitted entirely.

That is good security. It is also a total audit blind spot, and it is the reason this took an hour instead of a minute. We had a credential that was wrong in a way nothing could show us, in a store designed so that nobody — including us — could read it back to check.

The repro is two lines

The push script read the secret from the vault and piped it to the platform CLI. That pipe is the bug. Windows PowerShell 5.1:

'SECRETVALUE' | node -e "process.stdin.on('data',d=>console.log(JSON.stringify(d.toString())))"
# "SECRETVALUE\r\n"

There it is. Piping a string to a native command prefixes U+FEFF, because [Console]::OutputEncoding is UTF-8 with a 3-byte preamble in a non-interactive session:

[Console]::OutputEncoding.GetPreamble().Length   # 3

The CLI passed those bytes through faithfully. The platform stored them faithfully. Everything downstream was correct about a value that was already wrong.

Two fixes that do not work

The obvious fix is to set the output encoding to a UTF-8 that emits no preamble:

$OutputEncoding = New-Object System.Text.UTF8Encoding $false
'SECRETVALUE' | node -e "..."
# "SECRETVALUE\r\n"   <-- still there

Still there. So try the console encoding instead:

[Console]::OutputEncoding = New-Object System.Text.UTF8Encoding $false
'SECRETVALUE' | node -e "..."
# "SECRETVALUE\r\n"   <-- still there

Still there.

Both of those are the fixes you will find if you search for this, and we measured both of them failing before writing any code. That mattered: the first patch we wrote was the $OutputEncoding one, and it shipped a comment confidently explaining a fix that did nothing. A control run caught it.

The fix that does work

Stop using the pipe. Write the value to a file with an encoding you control, and redirect that file into the process's stdin:

$stdin = Join-Path $env:TEMP ([guid]::NewGuid().ToString() + '.in')
try {
    [IO.File]::WriteAllText($stdin, $plain, (New-Object System.Text.UTF8Encoding $false))
    $proc = Start-Process -FilePath $env:ComSpec `
        -ArgumentList @('/c', 'thecli', 'env', 'update', $name, 'production', '--yes') `
        -RedirectStandardInput $stdin -NoNewWindow -Wait -PassThru
    if ($proc.ExitCode -ne 0) { throw "push failed ($($proc.ExitCode))" }
}
finally { Remove-Item $stdin -Force -ErrorAction SilentlyContinue }

Verified at the byte level, which is the only verification that means anything here:

(Get-Content $stdin -Encoding Byte | Select-Object -First 4) -join ','
# 83,69,67,82   <-- "SECR", no preamble

Two things we hit on the way, in case you are doing the same:

The CLI needs --yes to overwrite an existing variable, or it exits 1 with confirmation_required — and you cannot answer the prompt, because stdin is carrying the secret.
Start-Process cannot launch an npm shim directly (%1 is not a valid Win32 application), hence going through %ComSpec%.

What we actually got wrong

The bug is a one-character encoding quirk. The reason it cost an hour is not.

A write-only secret cannot be audited by reading it. Sensitive storage removes the only check most people have. If you use it — and you should — then the verification has to be behavioural, not textual: after any push, make a real call with the stored credential and assert the response. Not "the CLI said Updated". Not "the row's updatedAt moved". An actual request.

We had that backwards. We trusted a success message from a tool that was faithfully transmitting corruption, about a value we had deliberately made unreadable, and we only found out when something unrelated fell over with an error about character 65279.

The encoding bug will bite someone else. The blind spot is the part worth fixing.

We audited our AI coding agent's own config. It failed.

RedCapra — Wed, 02 Sep 2026 22:07:36 +0000

Your AI coding agent runs with your permissions. All of them.

If it can read a file, it reads with your account. If it can run a shell command, that command can touch everything you can touch. Most of us set up these tools in five minutes, click "allow" a few times to make the prompts stop, and never look at the resulting config again.

This week we audited our own.

The idea came from a 246,000-star repo

We spent an evening reviewing ECC, the viral agent-harness kit. Our verdict on installing it was no — for our setup, ~90 scripts executing on every tool call is more supply-chain surface than we'll accept, and its flagship learning system is a documented no-op on native Windows, which is what we run.

But buried in it was one idea worth more than the whole repo: your agent tooling is part of your threat model. The settings files, the hooks, the MCP server definitions, the permission allowlists — that's an attack surface, and almost nobody audits it.

We ship a security scanner for a living. We had audited our web apps relentlessly. We had never audited our own agent configs.

What we found in our own house

Five parallel audit passes over every harness config on our build machine. Findings, in descending order of embarrassment:

One repo's local settings contained "Bash(*)" — a blanket shell allow. Any prompt injection reaching a session in that project could run arbitrary commands with zero approval prompt. It had been sitting there since some long-forgotten session where someone (fine: we) allowed it to make a prompt go away.
Another repo's settings allowed unprompted Read of the entire user profile — SSH keys, token caches, browser profiles, password-manager stores. Plus a python -c allow, which is arbitrary code execution wearing a lab coat.
OAuth token caches were readable and writable by every local account on the machine — inherited NTFS permissions nobody had ever looked at.
A global allow rule contradicted our own database doctrine — granted once in some session, applying forever, in every project.

The one that made us laugh: when our agent tried to fix the global permission file, the permission classifier blocked the agent from editing its own permissions. Correct behavior. The guard guarded the guardian, and the fix went through a human paste instead.

Everything above is closed now. Total time from "let's audit" to "all HIGHs fixed": about two hours. The Bash(*) had been live for weeks.

We turned the checklist into a free tool

The rule set from that audit is now a scanner you can run in your browser: redcapra.com/agent-scan.

Paste your settings.json, .mcp.json, or hooks config and it grades what it finds:

blanket and sudo shell wildcards, arbitrary-exec allows (python -c, sh -c, eval…), destructive-command allows
profile-wide Read grants and root-level additionalDirectories
missing .env read-deny nets
unpinned auto-installing MCP servers (npx -y something@latest executes whatever the registry serves next)
credentials sitting inline in MCP/env config
hook commands that interpolate tool input into shell strings, post to external hosts, or pipe downloads into sh

It's a few hundred lines of plain JavaScript running entirely in the page. Nothing you paste is uploaded, logged, or stored — credential-shaped values are masked before they even appear in the findings text. No account, no email gate.

Three things to check tonight, no tool required

Grep your settings files for Bash(*) — and for interpreter allows like python -c or sh -c, which are the same thing in disguise.
Look at every npx -y in your MCP config. Pin versions. @latest means "whatever ships next runs on my machine automatically."
Read your hooks like an attacker. Anything interpolating ${...} tool input into a shell string is command injection waiting for a crafted filename. Anything posting to a non-localhost URL is an exfiltration channel — transcripts contain secrets more often than you think.

Your agent is probably fine. Its config might not be. Ours wasn't — and we do this for a living.

RedCapra is a local-first security workbench: a real 47-check scan on your site, free, findings tracked in your browser. If the agent scanner is useful, the workbench is the same philosophy pointed at your web app.