A Markdown File Can Hijack Claude Code and Codex. Review What You Install.
A pack can change what your agent trusts and runs. Read its installation footprint before you give it your workspace.
You can catch a dangerous agent setup before it gets near your project by reading what the installer changes.
Start with the files that launch commands, redirect requests or apply across every project.
The awkward question comes when a pack contains more instructions than you can realistically review: what have you actually agreed to run?
A Markdown extension makes a file look harmless.
It opens in a text editor, has headings, and probably contains something reassuring about engineering standards.
But an instruction file has a reader with tools attached to it.
That changes what the words can do.
An agent pack can be useful.
It can also turn an installation decision into dozens of smaller decisions you never made explicitly.
You wanted help reviewing code.
You may also have accepted a startup command, a new server and a different place to send requests.
The file reached a real machine
Forever Security reported finding a malicious AGENTS.md in a customer's Downloads folder in October 2026.
The company says it stopped the attempted installation and could not establish how the file arrived.
In its own isolated reproduction, it reported success in more than 90% of Codex attempts.
Its separate Claude Code experiment redirected API traffic through a researcher-controlled endpoint and worked about 50% of the time.
These are vendor-reported results, not your odds of compromise.
The original report describes both experiments.
The 13 KB document belonged to the Codex case.
The Claude experiment used a different instruction file and a configuration change involving ANTHROPIC_BASE_URL.
Forever sells agent-security monitoring, so its conclusion that there is nothing to patch deserves scrutiny rather than repetition as a settled fact.
The connection to packs is an inference, and it is narrower than “agent packs contain malware.”
If an installer writes the same kinds of trusted configuration that an attacker wants an agent to write, it crosses a similar trust boundary.
The installer can be perfectly honest.
You still need to understand what you are authorizing.
An installation command tells your computer that you consent.
It cannot tell whether you understood the consequences.
The agent can notice and still obey
A preprint by Xiaonan Xu and Wenjing Wu, submitted on October 22, tested 40 constructed Python projects across 320 runs.
The instruction files deliberately disagreed with the code.
Without a corrective instruction, 90.1% of the measured choices followed the stale file.
Claude Code mentioned the conflict in 79 of 80 baseline runs and still tended to follow the file.
The authors attribute this to how the inputs arrive: the file supplies instructions, while the code arrives as tool output.
Their experiment concerns conflicting coding conventions, not malicious packs or successful intrusions.
It supports a limited but useful warning: noticing a contradiction does not ensure the agent resolves it the way you expect.
That is enough to change how you review an imported rule.
“The agent will notice if this makes no sense” is a poor substitute for deciding whether the rule belongs in your project.
The file can sound competent while being wrong for your setup.
It may simply describe its author's workflow, permissions or assumptions.
This is the other side of making your CLAUDE.md shape behavior.
Useful guidance works because it influences the agent.
Imported guidance gets that opportunity too.
Ask what each rule causes the agent to do, and under which conditions.
An instruction to run a local formatter is easy to relate to a task.
An instruction to prepare an unfamiliar service before doing anything else deserves a much closer look.
A pack can change several boundaries
The file types do different jobs.
Treating them as equally dangerous would obscure the parts worth examining first.
An instruction file influences decisions.
AGENTS.md supplies persistent guidance to Codex, with applicable instructions assembled from user and project locations.
It is not a shell executable merely because of its filename.
The risk depends on what the agent does with its contents and what its environment permits.
OpenAI documents how those instructions are discovered.
A skill can bring more than prose.
Claude Code skills can include supporting scripts, tool permissions and hooks in their frontmatter.
Reading only the explanation below the heading can miss configuration above it or files beside it.
The skills documentation describes these extension points.
A command hook runs a command.
Anthropic's hooks reference warns that command hooks run with the user's permissions and can access, change or delete accessible files.
It also describes workspace-trust checks, including differences between interactive and noninteractive sessions.
Do not confuse those checks with approving every subsequent hook execution.
Review the actual command and the script it calls.
The hooks reference states the execution and trust rules.
An MCP configuration connects a service.
A local server definition can launch a process, while a remote definition connects to a server elsewhere.
Claude Code has project-server approval and workspace-trust mechanisms.
The existence of an approval prompt does not explain what a selected server will do with the access you grant it.
The MCP documentation describes these connection types.
A settings file changes the environment around those decisions.
Claude distinguishes user settings, shared project settings and local project settings.
For Codex, user configuration normally lives in ~/.codex/config.toml, with project configuration available too.
An installer that writes a user-level file can affect unrelated work later.
Claude's scope documentation and Codex's configuration documentation explain the distinction.
Count the boundaries crossed before you count the features added.
A pack that solves a small problem with a local instruction has a different review burden from a pack that registers startup processes and changes your user configuration.
A safety hook still needs trust
A hook that blocks a destructive command can be useful.
It still runs through a mechanism that gives code access to your environment.
Calling the file “security” describes its intended job, not a separate class of permissions.
Imagine a hypothetical pack with a local command guard and an optional reporting feature.
The guard may make a simple decision from the command text.
The reporting feature may send data somewhere else.
You can approve the first and decline the second if the package lets you separate them.
If it does not, the bundled decision deserves to be explicit.
This is where a large feature list can become an inconvenient sales pitch.
You do not need every capability merely because the installer can enable it.
Useful defaults should still leave you able to explain what is running.
The problem resembles repeated approval prompts losing their meaning.
There is a difference between choosing a tool and accepting a sequence of changes whose details you have stopped reading.
A single installation can compress that sequence into a much more attractive button.
Read the footprint before you run
Give yourself a short first pass before installation.
A 10-minute window can be a useful time box for triage, but it is not a promise that a large pack can be audited in 10 minutes.
If you cannot explain the important parts when the time is up, leave them disabled.
Start with a plain-text view of the downloaded files.
Keep the coding agent out of the review folder until you have checked its instructions and startup configuration.
Read the installer as well as the files it proposes to install.
Look for destinations outside the project, fetched scripts and installation steps that execute code.
Use a file search to locate configuration rather than asking the pack to diagnose itself.
In a terminal, from a local copy, this command lists selected candidate files:
rg --files --hidden --no-ignore \
-g '!**/.git/**' -g '!**/node_modules/**' \
-g 'CLAUDE.md' -g 'AGENTS.md' -g 'AGENTS.override.md' \
-g 'SKILL.md' -g 'settings*.json' -g '*mcp*.json' \
-g 'hooks.json' -g 'config.toml' .This is an inventory aid.
It does not discover every possible executable or configuration source.
Follow the paths referenced inside the files you find, including files with ordinary names.
Treat symlinks and missing targets as things to resolve, not items to skip.
If you already have jq, the following reads the hooks block from a project settings file without executing it:
jq '.hooks // {}' .claude/settings.jsonA missing file or empty result only describes that location.
It says nothing about user settings, plugins or hooks elsewhere.
Read the scripts referenced by each command and identify any network destination they use.
An unfamiliar destination needs an explanation before it needs an allow rule.
You can also locate files containing endpoint-related names without printing their values:
rg -l --hidden --no-ignore \
-g '!**/.git/**' -g '!**/node_modules/**' \
'ANTHROPIC_BASE_URL|base_url|HTTPS?_PROXY' .A match may be legitimate documentation or an approved proxy.
No match does not prove the absence of a redirect.
Open the matching files locally and trace where the setting is consumed.
Avoid posting configuration dumps into a public issue, since they can contain credentials.
Then record the exact revision you reviewed, the features you intend to enable and the files the installer will write.
Pinning the pack to a commit makes that review reproducible.
If its commands fetch other packages or scripts, those are additional dependencies to inspect and pin where practical.
The pack's commit does not freeze a changing remote dependency.
The checklist leaves uncertainty visible
A review sheet cannot tell you whether a maintainer will lose control of an account next month.
It cannot infer the intention behind a network request, or prove that a readable script has no hidden behavior in its dependencies.
Those limits should change the decision, not disappear into a green badge.
Checkmarx's October 5 investigation linked function-color to the MALFEX campaign through function-flag.
It described Windows payloads and gaps in malware advisories.
That supports a warning about incomplete detection, not a claim that a clean package was later compromised or that the same payload infects every operating system.
The report separates the packages, dates and affected platform.
You can make a narrower decision than “I trust this pack.”
You can approve particular files at a particular revision for a particular project, with specific features left off.
You can keep an unresolved item unresolved rather than asking an AI to turn it into reassurance.
The useful outcome is a decision you can explain again after the installer has finished.
When a future update asks for more access, you have something concrete to compare it with.
And when you cannot explain a startup command, it can wait.
Your project does not owe a downloaded pack the opportunity to run.
Decide what your Claude Code and Codex packs may run
Keep the capabilities you need, identify what stays disabled, and record what you still need to verify.
Use the workbook to review a pack before installation and keep a decision you can compare against its next update.
[
Get the workbook for $19 USD.
I want this! Get the workbook on Gumroad →
You receive a 10-page PDF and seven editable Markdown files.
Gumroad adds applicable taxes at checkout.
The workbook supports a manual review; it does not certify that a pack is safe.
Sources
- Forever Security reports the observed file and its reproduction experiments in Markdown Is the New Executable.
- Xu and Wu describe their controlled experiment in Stale Instruction Files Override the Code in Coding Agents.
- Anthropic documents hooks, skills, MCP connections and settings scope.
- OpenAI documents instruction discovery and configuration scope.
- Checkmarx details the MALFEX campaign.
Sources were checked on October 27, 2026.
This article is about what happens when you install an agent pack without reading what it actually authorizes. The Production CLAUDE.md template in the welcome kit shows you how to document agent rules and deny-lists, so you know exactly what you're letting run.