Hadolint Dockerfile Diagnostics Hook for Claude Code
Read-only Claude Code PostToolUse hook that runs Hadolint diagnostics after Claude writes or edits Dockerfile-like files, surfacing Dockerfile best practice, inline shell, trusted registry, label, and configuration findings without rewriting files.
This hook runs a local `hadolint --format gnu` command only. It does not build images, run containers, pull base images, install Hadolint, rewrite files, or execute Dockerfile instructions., The hook exits non-zero when Hadolint reports diagnostics. Depending on Claude Code settings, this can interrupt the workflow until a human reviews the output., Keep the hook scoped to write/edit tools. Running Hadolint after every tool call can add noise and slow down projects with generated Dockerfiles., Hadolint findings are static-analysis findings, not proof that an image build is safe, reproducible, minimal, or vulnerability-free., Hadolint can respect project configuration files and inline ignore pragmas. Review `.hadolint.yaml` and ignored rules before treating a clean result as sufficient., This script intentionally avoids the official Docker and Podman invocation paths so a hook run does not require Docker socket access or container image pulls., Review base image trust, package manager commands, copied files, build secrets, and runtime privileges separately from this hook.
Privacy notes
Hadolint diagnostics can include file paths, image names, registry hostnames, labels, build arguments, environment variable names, comments, and Dockerfile snippets., Dockerfiles can reveal private registry names, internal service names, proprietary package mirrors, deployment paths, and application structure., Hook output can be retained in Claude Code logs, terminal scrollback, screenshots, support tickets, issue comments, or AI transcripts., Avoid pasting proprietary Dockerfiles, private image names, customer deployment paths, secret variable names, or internal registry details into public comments or prompts.
Author
Hadolint
Submitted by
oktofeesh1
Claim status
unclaimed
Last verified
2026-06-04
Decision playbook
Review trust signals before you adopt
Signals are present but mixed. Use the checklist below to confirm the source and operational safety for your environment.
Compare context
Selected
0
Current score
78
Baseline
—
Delta
No baseline selected
No major trust-signal divergence detected in the current selection.
Source and provenance checks
Complete
Confirm ownership and provenance before trusting install instructions.
Source link availableRequired
Open the canonical repository and verify ownership.
Done
Source provenance statusRequired
Marked as source-backed.
Done
Metadata reviewed
Registry metadata indicates a reviewed listing.
Done
Safety and privacy checks
Complete
Validate risk disclosures before installation or API wiring.
Safety notes presentRequired
Review the listed safety guidance before running commands.
Done
Privacy notes presentRequired
Review data handling notes before connecting accounts or secrets.
Done
Trust level risk gateRequired
Trust level does not block evaluation.
Done
Package and install checks
Needs review
Check package metadata and artifact integrity signals.
Install payload available
Install or copy payload is available for review.
Done
Package verification flag
No package verification flag provided.
Pending
Checksum metadata
No checksum provided for downloaded artifact.
Pending
Compare-driven decision checks
Needs review
Use compare context to validate trade-offs before adoption.
Compare tray has multiple entries
Add at least one more entry to compare trust differences.
7 safety and 4 privacy notes across 5 risk areas. Review closely: credentials & tokens, permissions & scopes.
5 areas
SafetyLocal filesThis hook runs a local `hadolint --format gnu` command only. It does not build images, run containers, pull base images, install Hadolint, rewrite files, or execute Dockerfile instructions.
SafetyGeneralThe hook exits non-zero when Hadolint reports diagnostics. Depending on Claude Code settings, this can interrupt the workflow until a human reviews the output.
SafetyPermissions & scopesKeep the hook scoped to write/edit tools. Running Hadolint after every tool call can add noise and slow down projects with generated Dockerfiles.
SafetyGeneralHadolint findings are static-analysis findings, not proof that an image build is safe, reproducible, minimal, or vulnerability-free.
SafetyLocal filesHadolint can respect project configuration files and inline ignore pragmas. Review `.hadolint.yaml` and ignored rules before treating a clean result as sufficient.
SafetyLocal filesThis script intentionally avoids the official Docker and Podman invocation paths so a hook run does not require Docker socket access or container image pulls.
SafetyCredentials & tokensReview base image trust, package manager commands, copied files, build secrets, and runtime privileges separately from this hook.
PrivacyLocal filesHadolint diagnostics can include file paths, image names, registry hostnames, labels, build arguments, environment variable names, comments, and Dockerfile snippets.
PrivacyLocal filesDockerfiles can reveal private registry names, internal service names, proprietary package mirrors, deployment paths, and application structure.
PrivacyExecution & processesHook output can be retained in Claude Code logs, terminal scrollback, screenshots, support tickets, issue comments, or AI transcripts.
PrivacyCredentials & tokensAvoid pasting proprietary Dockerfiles, private image names, customer deployment paths, secret variable names, or internal registry details into public comments or prompts.
Safety notes
This hook runs a local `hadolint --format gnu` command only. It does not build images, run containers, pull base images, install Hadolint, rewrite files, or execute Dockerfile instructions.
The hook exits non-zero when Hadolint reports diagnostics. Depending on Claude Code settings, this can interrupt the workflow until a human reviews the output.
Keep the hook scoped to write/edit tools. Running Hadolint after every tool call can add noise and slow down projects with generated Dockerfiles.
Hadolint findings are static-analysis findings, not proof that an image build is safe, reproducible, minimal, or vulnerability-free.
Hadolint can respect project configuration files and inline ignore pragmas. Review `.hadolint.yaml` and ignored rules before treating a clean result as sufficient.
This script intentionally avoids the official Docker and Podman invocation paths so a hook run does not require Docker socket access or container image pulls.
Review base image trust, package manager commands, copied files, build secrets, and runtime privileges separately from this hook.
Privacy notes
Hadolint diagnostics can include file paths, image names, registry hostnames, labels, build arguments, environment variable names, comments, and Dockerfile snippets.
Dockerfiles can reveal private registry names, internal service names, proprietary package mirrors, deployment paths, and application structure.
Hook output can be retained in Claude Code logs, terminal scrollback, screenshots, support tickets, issue comments, or AI transcripts.
Avoid pasting proprietary Dockerfiles, private image names, customer deployment paths, secret variable names, or internal registry details into public comments or prompts.
Prerequisites
Claude Code project where hooks are allowed by user or project policy.
Hadolint installed locally and available on `PATH`, for example through an operating system package manager or official release path.
`jq` available on the machine to parse Claude Code hook input.
A reviewed `.claude/settings.json` or user settings hook configuration for `Write`, `Edit`, and `MultiEdit`.
Agreement that Dockerfile diagnostics should be blocking or interrupting when Hadolint reports findings.
Optional project `.hadolint.yaml` or equivalent config reviewed before relying on ignored rules, trusted registries, required labels, or severity thresholds.
Schema details
Install type
cli
Reading time
7 min
Difficulty score
60
Troubleshooting
Yes
Breaking changes
No
Source repository stats
Scope
Source repo
Runtime and command metadata
Trigger
PostToolUse
Script language
bash
Script body
#!/usr/bin/env bash
set -uo pipefail
input="$(cat)"
if ! command -v jq >/dev/null 2>&1; then
echo "Hadolint hook skipped: jq is required to parse Claude Code hook input." >&2
exit 0
fi
tool_name="$(printf '%s' "$input" | jq -r '.tool_name // .toolName // empty')"
file_path="$(printf '%s' "$input" | jq -r '.tool_input.file_path // .tool_input.path // .toolInput.file_path // .toolInput.path // empty')"
case "$tool_name" in
Write|Edit|MultiEdit|write|edit|multiedit) ;;
*) exit 0 ;;
esac
if [ -z "$file_path" ] || [ ! -f "$file_path" ] || [ ! -r "$file_path" ]; then
exit 0
fi
file_name="$(basename "$file_path")"
case "$file_name" in
Dockerfile|Dockerfile.*|*.Dockerfile|*.dockerfile|Containerfile|Containerfile.*|*.Containerfile|*.containerfile) ;;
*) exit 0 ;;
esac
if ! command -v hadolint >/dev/null 2>&1; then
echo "Hadolint hook skipped: install hadolint to enable Dockerfile diagnostics." >&2
exit 0
fi
echo "Hadolint hook: checking $file_path" >&2
hadolint --format gnu "$file_path"
status=$?
if [ "$status" -ne 0 ]; then
echo "Hadolint hook: diagnostics found. Review Dockerfile rules, inline shell, pinned images, labels, and trusted registry policy before asking Claude to continue." >&2
fi
exit "$status"
This hook runs Hadolint after Claude Code writes or edits a Dockerfile-like
file. It is intentionally read-only: it reports diagnostics and exits non-zero
when Hadolint reports findings, but it does not build images, run containers,
pull base images, install packages, rewrite Dockerfiles, or execute Dockerfile
instructions.
Use it when a project contains Dockerfiles and you want immediate feedback on
Dockerfile best practices, inline shell in RUN instructions, pinned images,
trusted registries, label policy, package manager usage, and project Hadolint
configuration after Claude edits a file.
These sources were reviewed on 2026-06-04. The official Hadolint README
describes Hadolint as a Dockerfile linter that parses Dockerfiles into an AST,
applies rules, and uses ShellCheck for Bash inside RUN instructions. It also
documents local binary use, Docker and Podman invocation options, CLI output
formats, ignored rules, trusted registries, label checks, severity thresholds,
and configuration file lookup.
Installation
Install Hadolint locally through an operating system package manager or the
official Hadolint release path.
Confirm hadolint --help works in the same environment Claude Code uses.
Confirm jq is available.
Save the script as .claude/hooks/hadolint-dockerfile-diagnostics.sh.
Make it executable.
Add the hook configuration to .claude/settings.json or user settings after
reviewing the behavior with your team.
Save this as .claude/hooks/hadolint-dockerfile-diagnostics.sh and make it
executable:
#!/usr/bin/env bash
set -uo pipefail
input="$(cat)"
if ! command -v jq >/dev/null 2>&1; then
echo "Hadolint hook skipped: jq is required to parse Claude Code hook input." >&2
exit 0
fi
tool_name="$(printf '%s' "$input" | jq -r '.tool_name // .toolName // empty')"
file_path="$(printf '%s' "$input" | jq -r '.tool_input.file_path // .tool_input.path // .toolInput.file_path // .toolInput.path // empty')"
case "$tool_name" in
Write|Edit|MultiEdit|write|edit|multiedit) ;;
*) exit 0 ;;
esac
if [ -z "$file_path" ] || [ ! -f "$file_path" ] || [ ! -r "$file_path" ]; then
exit 0
fi
file_name="$(basename "$file_path")"
case "$file_name" in
Dockerfile|Dockerfile.*|*.Dockerfile|*.dockerfile|Containerfile|Containerfile.*|*.Containerfile|*.containerfile) ;;
*) exit 0 ;;
esac
if ! command -v hadolint >/dev/null 2>&1; then
echo "Hadolint hook skipped: install hadolint to enable Dockerfile diagnostics." >&2
exit 0
fi
echo "Hadolint hook: checking $file_path" >&2
hadolint --format gnu "$file_path"
status=$?
if [ "$status" -ne 0 ]; then
echo "Hadolint hook: diagnostics found. Review Dockerfile rules, inline shell, pinned images, labels, and trusted registry policy before asking Claude to continue." >&2
fi
exit "$status"
What It Checks
Dockerfile-like files such as Dockerfile, Dockerfile.prod,
service.Dockerfile, and Containerfile.
Hadolint's Dockerfile rules and output in gnu format.
Inline shell diagnostics for Bash code inside RUN instructions through
Hadolint's ShellCheck-backed behavior.
Project-level Hadolint configuration when present and discoverable by the
Hadolint binary.
What It Does Not Do
It does not build images.
It does not run Docker, Podman, or containerized Hadolint.
It does not pull base images or contact registries.
It does not install Hadolint.
It does not rewrite Dockerfiles or apply auto-fixes.
It does not scan image layers, packages, CVEs, SBOMs, or runtime
capabilities.
It does not approve secrets, credentials, private registries, or production
deployment settings.
Troubleshooting
Hook says Hadolint is missing
Install Hadolint through an operating system package manager, official release,
or another reviewed local installation path. Confirm command -v hadolint
works in the same shell environment Claude Code uses.
Hook does not run for a Dockerfile
This script intentionally matches Dockerfile-like basenames. Rename generated or
custom files to a recognized Dockerfile pattern, or extend the case statement
after reviewing the project naming convention.
Hadolint reports findings that the team intentionally ignores
Prefer a reviewed project Hadolint configuration or scoped inline ignore
comments. Keep ignored rules visible in review so the team understands why a
rule is suppressed.
Dockerfile passes but the image is still unsafe
Hadolint is static Dockerfile analysis. Pair it with image builds, vulnerability
scans, SBOM review, secret scanning, runtime user checks, and registry policy
where those controls matter.
Duplicate Check
No existing content/hooks, content/skills, content/agents,
content/mcp, or content/tools entry in this checkout matches Hadolint,
hadolint/hadolint, hadolint.github.io, or a Dockerfile diagnostics hook.
Open PR titles, branch names, changed files, issue titles, issue bodies, and
source URLs were also checked before drafting this entry.
This entry is distinct from the existing ShellCheck hook. ShellCheck is focused
on shell scripts; this hook is focused on Dockerfile best-practice diagnostics
and Hadolint's Dockerfile parser/rule set, while still benefiting from
Hadolint's ShellCheck-backed RUN instruction analysis.
Editorial Disclosure
This is an independent, source-backed HeyClaude content entry submitted by
oktofeesh1. It is not sponsored by Hadolint or the Hadolint maintainers. The
hook expects a user-installed Hadolint binary and does not package,
redistribute, or verify a Hadolint release artifact.
Show that Hadolint Dockerfile Diagnostics Hook for Claude Code is listed on HeyClaude. Paste this Markdown into your README — it renders the badge and links back to this page.
[](https://heyclau.de/entry/hooks/hadolint-dockerfile-diagnostics-hook)
How it compares
Hadolint Dockerfile Diagnostics Hook for Claude Code side by side with 3 alternatives on trust, install, platform support, and disclosed safety notes — all from reviewed registry metadata.
Read-only Claude Code PostToolUse hook that runs Hadolint diagnostics after Claude writes or edits Dockerfile-like files, surfacing Dockerfile best practice, inline shell, trusted registry, label, and configuration findings without rewriting files.
Read-only Claude Code PostToolUse hook that runs ShellCheck diagnostics after Claude writes or edits shell scripts, reporting shell portability, quoting, expansion, error-handling, and command-safety issues without modifying files.
Read-only Claude Code PostToolUse hook that runs Biome's formatter, linter, and import-sorting checks on edited JavaScript, TypeScript, JSON, CSS, and GraphQL files without auto-writing changes.
✓This hook runs a local `hadolint --format gnu` command only. It does not build images, run containers, pull base images, install Hadolint, rewrite files, or execute Dockerfile instructions.
The hook exits non-zero when Hadolint reports diagnostics. Depending on Claude Code settings, this can interrupt the workflow until a human reviews the output.
Keep the hook scoped to write/edit tools. Running Hadolint after every tool call can add noise and slow down projects with generated Dockerfiles.
Hadolint findings are static-analysis findings, not proof that an image build is safe, reproducible, minimal, or vulnerability-free.
Hadolint can respect project configuration files and inline ignore pragmas. Review `.hadolint.yaml` and ignored rules before treating a clean result as sufficient.
This script intentionally avoids the official Docker and Podman invocation paths so a hook run does not require Docker socket access or container image pulls.
Review base image trust, package manager commands, copied files, build secrets, and runtime privileges separately from this hook.
✓This hook runs `shellcheck --format=gcc` only. It does not add `--external-sources`, install dependencies, rewrite files, run scripts, source scripts, or execute commands from the edited file.
The hook exits non-zero when ShellCheck reports diagnostics. Depending on Claude Code settings, this can interrupt the workflow until a human reviews the output.
Keep the hook scoped to write/edit tools. Running ShellCheck after every tool call can add noise and slow down shell-heavy projects.
ShellCheck warnings are static-analysis findings, not proof that a script is safe. Review command execution, permissions, inputs, secrets, paths, and deployment context separately.
ShellCheck can follow sourced files when configured to do so. This script avoids `--external-sources` by default so it does not traverse additional project files unexpectedly.
Do not use this hook as a blanket command blocker. It is intended to surface diagnostics after Claude edits shell files, not to approve or deny arbitrary terminal commands.
✓This hook runs `biome check` without `--write`, so it reports formatter, linter, and import-sorting diagnostics but does not modify files.
Do not add `--write` or `--unsafe` until the team has reviewed the hook behavior, backup expectations, and failure mode for generated edits.
The hook exits non-zero when Biome reports diagnostics. Depending on Claude Code settings, this can interrupt the current workflow until issues are reviewed.
Use a project-pinned Biome package when possible. The script prefers `./node_modules/.bin/biome` and avoids network-install fallbacks.
Keep matchers scoped to write/edit tools. Running Biome after every tool call can add noise and slow down large projects.
✓This hook is static and read-only. It reads only non-symlinked Wrangler config files inside the current project and does not run `wrangler deploy`, `wrangler dev`, `wrangler whoami`, `wrangler secret list`, package scripts, build plugins, or network commands.
The hook exits non-zero only for parse failures or missing required top-level Worker fields such as `name` and `compatibility_date`; warnings remain advisory so the user can review them.
The TOML checks are heuristic and do not replace Wrangler's own parser or a trusted pre-deploy dry run. Use them as a fast edit-time guard, then run official Wrangler validation in a trusted repository.
Do not expand this hook into a dry-run deploy hook unless the team has reviewed local build-script execution, inherited environment variables, and output-directory cleanup.
Keep matchers scoped to config file edits. Running config checks after every tool call adds noise without improving Cloudflare safety.
Privacy notes
✓Hadolint diagnostics can include file paths, image names, registry hostnames, labels, build arguments, environment variable names, comments, and Dockerfile snippets.
Dockerfiles can reveal private registry names, internal service names, proprietary package mirrors, deployment paths, and application structure.
Hook output can be retained in Claude Code logs, terminal scrollback, screenshots, support tickets, issue comments, or AI transcripts.
Avoid pasting proprietary Dockerfiles, private image names, customer deployment paths, secret variable names, or internal registry details into public comments or prompts.
✓ShellCheck diagnostics can include file paths, line numbers, command names, variable names, comments, and source snippets from edited shell scripts.
Hook output can be retained in Claude Code logs, terminal scrollback, screenshots, support tickets, issue comments, or AI transcripts.
Avoid pasting proprietary deployment scripts, customer paths, secret variable names, generated tokens, hostnames, or production command output into public comments or prompts.
Use synthetic examples when sharing ShellCheck findings publicly, and review diagnostics before exposing private repository structure.
✓Biome diagnostics can include file paths, rule names, code excerpts, import names, comments, and source snippets from edited files.
Claude Code hook logs, terminal scrollback, screenshots, support tickets, and AI transcripts can retain Biome diagnostics outside the repository.
Avoid pasting real customer code, private filenames, generated secrets, or proprietary source excerpts from hook output into public issue comments.
✓The hook reads `wrangler.toml`, `wrangler.json`, or `wrangler.jsonc` only inside the current project, with symlinks rejected and a 1 MiB size cap.
Wrangler config files can contain worker names, route patterns, account identifiers, resource IDs, binding names, environment names, analytics settings, and non-secret vars.
Hook output may include file paths, config key names, environment names, and secret-like variable names, so avoid pasting terminal logs into public issue comments without review.
If a Wrangler config currently contains real secrets in `vars`, the hook can reveal the key names and the surrounding configuration context. Move sensitive values to Wrangler secrets before sharing output.
Prerequisites
Claude Code project where hooks are allowed by user or project policy.
Hadolint installed locally and available on `PATH`, for example through an operating system package manager or official release path.
`jq` available on the machine to parse Claude Code hook input.
A reviewed `.claude/settings.json` or user settings hook configuration for `Write`, `Edit`, and `MultiEdit`.
Claude Code project where hooks are allowed by user or project policy.
ShellCheck installed on the machine, for example through the operating system package manager or the official ShellCheck release path.
`jq` available on the machine to parse Claude Code hook input.
A reviewed `.claude/settings.json` or user settings hook configuration for `Write`, `Edit`, and `MultiEdit`.
Claude Code project where hooks are allowed by user or project policy.
Project-local Biome install, usually `pnpm add -D @biomejs/biome` or the equivalent package-manager command.
`jq` available on the machine to parse Claude Code hook input.
A reviewed `.claude/settings.json` or user settings hook configuration for `Write`, `Edit`, and `MultiEdit`.
Claude Code project where hooks are allowed by user or project policy.
Cloudflare Workers or Pages project with `wrangler.toml`, `wrangler.json`, or `wrangler.jsonc` checked into the repository.
`jq` available locally to parse Claude Code hook input.
Node.js available locally for static JSON/JSONC/TOML heuristics.