Agent Config Files Are Executable Supply Chain

Official Sources

The most important Hacker News security story for AI developers today was not a model exploit.

It was a config file.

SafeDep's Config Files That Run Code writeup hit the HN front page with a blunt lesson: files that look like tooling metadata can become execution triggers. The examples cross Claude Code, Gemini CLI, Cursor, VS Code, npm, Composer, and Bundler. Some run when a folder opens. Some run when an agent session starts. Some run during normal package-manager work.

That lands differently in 2026 because coding agents are no longer just reading source files. They are reading project instructions, loading skills, obeying editor rules, starting hooks, connecting tools, and running commands inside trusted folders.

The take: agent config files are executable supply chain.

Not every config file literally executes shell. But once a file can shape what an agent trusts, what it runs, what it ignores, or which tool it connects, it belongs in code review.

This is the sharper version of the argument in Agent Skills Are Becoming Package Managers. Skills and plugins are dependencies. Hooks and config files are the trigger layer underneath them.

The Blind Spot Is Familiar

Developers already know to review application code.

They are worse at reviewing the files that surround application code:

• .claude/settings.json
• .gemini/settings.json
• .cursor/rules/*.mdc
• .vscode/tasks.json
• package.json scripts
• composer.json scripts
• Gemfile
• Makefile
• Taskfile.yml
• devcontainer.json
• .github/workflows/*.yml

Those files feel like scaffolding. They sit in dotfolders, setup directories, package manifests, and editor config. They are easy to skim because they do not look like product logic.

That is exactly why attackers like them.

SafeDep's examples are useful because they separate three concepts that teams often blur together:

• Trigger: what causes the file to be read.
• Authority: what permission gate exists before action happens.
• Grammar: whether the file can carry a command, code, or instruction that makes another tool run code.

That model is more useful than a giant denylist. A config file becomes dangerous when an ordinary developer action crosses all three: open the folder, start the agent, run tests, install dependencies, or let CI restore a cache.

If you are building around Claude Code, Codex, Cursor, Gemini CLI, or any multi-agent workflow, this is now part of the agent threat model.

Agent Hooks Change The Meaning Of "Open The Repo"

Opening a repository used to be mostly passive.

That is no longer a safe assumption.

Claude Code supports hooks that can run commands around lifecycle events. Gemini CLI has a trusted-folder model. Cursor loads rules into the coding context. VS Code can run tasks after workspace trust. Package managers can run scripts during install, test, or framework boot.

Each system has different prompts and safeguards. That matters. It is wrong to flatten them into "all tools silently execute everything."

The better point is narrower: a repo can now carry instructions that change the agent runtime before the human has inspected the project.

That is a major workflow shift.

For a solo developer, the risk is mostly local compromise and wasted time. For a team, it is more subtle:

• a repo-local hook trains every agent session to run a setup script;
• an always-applied Cursor rule tells the assistant to execute a script;
• a package script makes "run tests" a launcher;
• a devcontainer command turns onboarding into execution;
• a CI workflow turns an agent-authored config tweak into a credential boundary problem.

This is why TanStack's npm compromise mattered for agent teams even though AI did not cause it. Agents inherit the trust boundaries around the files they edit.

The Opposing View Is Partly Right

The skeptical take from HN is fair: many of these vectors are old.

Package scripts are old. Editor tasks are old. Gemfiles are Ruby. Build systems have run commands forever. Workspace trust exists because editors have known this problem for years.

That is all true.

But AI coding agents change the operating pattern in three ways.

First, agents normalize starting work by pointing a powerful tool at an unfamiliar folder. A human may browse a repo in a web UI first. An agent session often begins inside the checkout.

Second, agents are good at following local instructions. That is the feature. A malicious or stale rule does not need to exploit a parser if it can convince the agent that "setup" is part of the job.

Third, teams are installing skill and plugin ecosystems across tools. Today's GitHub trending page included google/skills, openai/plugins, and several agent workflow repos. That does not mean those projects are unsafe. It means the market is moving toward portable agent instructions, which makes provenance and review more important.

This is the same direction as Claude Code plugin URL supply-chain risk, but the trigger surface is broader than plugin installs.

Review Config Like Code

The simplest rule is the one most teams will resist because it is boring:

Review agent config like code.

That means dotfolders and manifests deserve real review when they change. Not a glance. A review.

For agent-heavy teams, a PR should get extra scrutiny when it touches:

• agent settings, hooks, skills, plugins, or memory files;
• editor rules, tasks, launch configs, or workspace files;
• package-manager scripts and lifecycle hooks;
• CI workflows, cache behavior, OIDC, secrets, or release jobs;
• container lifecycle commands;
• files that tell agents to run scripts or trust generated output.

This does not mean banning automation. It means treating automation entrypoints as authority-bearing code.

The review question is not "does this file look like config?"

The review question is "what will read this file, when, and what can it make that tool do?"

Add A Config Receipt To Agent Runs

If a team uses agents for real engineering work, the final handoff should include the active runtime surface.

For anything security-sensitive, CI-adjacent, or dependency-related, ask the agent to leave a config receipt:

agent_runtime:
  repo_trust: "new clone, trusted after manual review"
  active_instruction_files:
    - "AGENTS.md"
    - ".claude/settings.json"
    - ".cursor/rules/frontend.mdc"
  hooks_seen:
    - file: ".claude/settings.json"
      event: "SessionStart"
      command_reviewed: true
  package_scripts_changed: false
  ci_or_release_files_changed: false
  external_plugins:
    - source: "none"
verification:
  config_scan: "passed"
  tests:
    - "pnpm typecheck"
    - "pnpm lint"

This is deliberately small. It does not require a new security platform. It just forces the run to name the config that shaped the work.

That connects to permissions, logs, and rollback for AI coding agents. You cannot audit an agent run if you only look at the diff. You also need to know the instruction and execution surface active during the run.

A Cheap Local Scan

Before opening an untrusted repo in an agent-enabled editor, scan it from the terminal or a web UI.

Start with the files that can trigger execution:

find . -maxdepth 4 -type f \
  \( -path './.claude/*' \
  -o -path './.gemini/*' \
  -o -path './.cursor/*' \
  -o -path './.vscode/*' \
  -o -path './.github/workflows/*' \
  -o -name 'package.json' \
  -o -name 'composer.json' \
  -o -name 'Gemfile' \
  -o -name 'Makefile' \
  -o -name 'Taskfile.yml' \
  -o -name 'devcontainer.json' \) \
  -print

Then inspect for obvious launchers:

rg -n "SessionStart|hooks|runOn|postinstall|preinstall|post-install-cmd|system\\(|curl|wget|bash|node .github|python -c|id-token: write|pull_request_target" \
  .claude .gemini .cursor .vscode .github package.json composer.json Gemfile Makefile Taskfile.yml .devcontainer 2>/dev/null

This is not a complete security scanner. It is a habit.

The point is to stop treating repo open, agent start, dependency install, and test run as harmless setup steps.

The Policy I Would Put In AGENTS.md

For teams, I would make this explicit:

Agent config, editor config, package scripts, CI workflows, and container lifecycle commands are executable supply chain.
Agents may read and summarize these files.
Agents may propose changes to these files.
Agents may not silently add or modify hooks, lifecycle scripts, release credentials, OIDC permissions, plugin sources, or trusted-folder behavior.
Any change to those files requires a human-readable receipt: trigger, authority, command, scope, and rollback path.

That policy is not anti-agent. It is what makes agents usable in repos where the surrounding tooling has real authority.

The next stage of agent security will not be one giant sandbox. It will be a set of boring boundaries around the small files that decide what the sandbox runs.

The Takeaway

Config files are no longer background noise.

In agentic development, they are part of the runtime.

Skills decide procedure. Hooks decide timing. Editor rules decide context. Package scripts decide what "test" means. CI decides which secrets and publish paths are reachable.

If those files are unreviewed, the agent is not operating in a trusted environment. It is operating in an environment that might have been shaped before the task began.

So review the config. Pin the skills. Keep plugins visible. Log hooks in the final receipt. Treat every file that can change agent behavior as supply chain.

That is the practical security posture for teams that want coding agents to do real work without turning every repo into an ambient execution surface.

FAQ

Are agent config files actually executable?

Some are directly executable through hooks, tasks, lifecycle scripts, or language-specific manifests. Others are indirectly executable because they instruct an agent to run commands or connect tools. Both categories need review.

Should teams ban Claude Code hooks or editor tasks?

No. Hooks and tasks are useful when they are explicit, scoped, reviewed, and logged. The risk is hidden or stale automation that runs before the team understands the repo.

What should reviewers check first?

Check trigger, authority, command, scope, and rollback. Ask what reads the file, when it runs, what permission gate exists, what command or instruction it carries, and how to disable it quickly.

How does this differ from normal supply-chain security?

The underlying primitives are familiar, but coding agents amplify them. Agents follow local instructions, start sessions inside checkouts, and increasingly load skills and plugins across projects. That makes config provenance part of agent safety.