Codex CLI prompt injection on Windows exposes a host execution gap

At a glance

What this is: Cymulate says a web-search prompt injection in Codex CLI for Windows can plant a batch file and cause code execution outside the sandbox on the next run.

Why it matters: This matters because AI coding agents that can read web content and write files create a blended identity and endpoint risk, where untrusted instructions can turn into privileged host actions through the same workflow.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.

👉 Read Cymulate's analysis of Codex CLI prompt injection and Windows host execution

Context

Codex CLI for Windows shows how AI coding agents can inherit risk from the browser, the filesystem, and the operating system at the same time. The primary problem is not the model itself, but the trust boundary around external content, file writes, and runtime resolution, which makes prompt injection and binary hijacking a practical execution path.

In identity terms, the article points to a governance gap around non-human identities that can both consume untrusted web content and act on local resources. In endpoint terms, it shows why sandboxing alone does not eliminate host execution risk when process lookup, working directories, and tool outputs are still part of the attack surface.

Key questions

Q: What breaks when AI coding agents can read web content and write local files?

A: The trust boundary breaks. A retrieval step can become a code execution path when an AI agent is allowed to ingest external pages, write files into a working directory, and later influence startup behaviour. That combination turns prompt injection into persistence, because the malicious instruction survives the session and can execute when the tool restarts.

Q: Why do AI agents create more risk than traditional automation?

A: AI agents create more risk because they can interpret context, choose actions, and invoke tools autonomously. Traditional automation follows fixed rules, but an agent can be manipulated into using its own authority in unintended ways. That makes permission scope, tool boundaries, and monitoring more important than model accuracy alone.

Q: How can organisations tell whether an AI agent is operating outside its intended boundary?

A: Look for inconsistent classifications, premature tool calls, fabricated inputs, and responses that ignore structured guardrails. Those signals show the agent is optimising for task completion rather than respecting the workflow boundary. The safest response is to tighten the schema and review the tool path, not just rewrite the prompt.

Q: Who is accountable when an AI agent turns external content into host compromise?

A: Accountability spans the application owner, the security team, and the business unit that approved the tool. If the agent can access the web, write files, and execute locally, then governance must cover procurement, endpoint hardening, and logging. The control failure is shared, so responsibility must be explicit before deployment.

Technical breakdown

How prompt injection enters the agent context

Codex CLI's web.run flow searches the web, loads result pages, and injects page content into the model context. If an attacker controls a publicly indexed page, the page can carry instructions that look like normal task guidance but are actually malicious. The model does not distinguish between helpful context and adversarial content unless the application enforces a trust boundary. That makes the search step a content ingestion pipeline, not just a retrieval feature.

Practical implication: treat every external page consumed by an AI agent as untrusted input and restrict which sources the agent can read.

Why binary hijacking defeats the sandbox on Windows

The report describes a file planting step where the agent creates node.bat in the working directory. On Windows, executable resolution can prefer the current directory, and Codex CLI later looks up the Node.js runtime by name rather than a fixed absolute path. That combination lets a planted file execute from the host context when the tool starts again. The sandbox is bypassed because the runtime lookup happens outside the intended file and process boundary.

Practical implication: enforce absolute-path execution and block writable working directories from being used as launch locations for AI CLIs.

Why agentic file-write capability creates persistence

The key architectural issue is that the agent can translate model output into filesystem changes without a human confirming the intent. Once a malicious file is written, it survives the session and becomes a persistence mechanism for later execution. This is why agentic tools differ from chat interfaces. They can turn a single injected instruction into a delayed execution chain that reactivates when the application is restarted.

Practical implication: monitor file creation in execution-sensitive paths and require approval before an AI agent writes files that can influence startup behaviour.

Threat narrative

Attacker objective: The attacker wants persistent arbitrary code execution on a Windows host through an AI coding agent workflow.

1. Entry occurs when the attacker places malicious instructions on a publicly indexed web page that a user is likely to retrieve through Codex CLI web.run.
2. Credential or execution access is gained when the agent processes the injected content and writes a malicious node.bat file into the working directory.
3. Impact occurs when Codex CLI later resolves the planted file during startup and executes attacker-controlled code outside the sandbox on the host.

Breaches seen in the wild

• Amazon Q AI Coding Agent Compromised — Amazon Q AI coding agent compromised via prompt injection enabling hackers to inject data-wiping commands.
• Gemini AI Breach — Google Calendar Prompt Injection — Gemini AI assistant prompt injection attack leaks sensitive Google Calendar data.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Prompt injection is now an execution-path problem, not just a content-safety problem. The agent does not merely read untrusted text. It can act on that text through file writes, command execution, and runtime resolution, which turns retrieval into a control-plane issue. That matters for AI governance because the trust decision is happening at the point where external content becomes operational output, not at the model boundary alone. Practitioners should classify external content ingestion as a privileged workflow.

Binary hijacking shows why host execution rules matter more than model intent. The failure mode here is not that the model understood malicious content, but that Windows search order and name-based runtime lookup let a planted file win. This is a classic execution governance gap wrapped inside an AI workflow. The named concept is runtime resolution hijack: when agent output or local file placement changes what executable the host launches. Practitioners should treat host execution paths as part of AI control design.

AI coding agents are non-human identities with filesystem side effects. Once a tool can retrieve web content, write files, and trigger local execution, it behaves like a governed identity rather than a passive assistant. That creates an overlap between NHI governance and endpoint security that most teams still manage separately. OWASP-NHI and OWASP Agentic AI guidance both become relevant because the issue is identity plus delegation plus tool use, not just prompt quality. Practitioners should build cross-domain controls around tool-scoped privileges.

Sandboxing reduces blast radius, but it does not replace execution governance. The report shows that a restricted user context is not enough if the agent can still influence the host process, startup files, or executable search order. This is where NIST CSF, MITRE ATT&CK, and NHI governance intersect: the control objective is not only detection, but preventing the agent from becoming a bridge between untrusted content and host compromise. Practitioners should measure whether their AI toolchain can be forced to execute outside intended boundaries.

Security teams need to reframe AI CLI review as a supply chain and endpoint problem. The attack chain spans web content, tool execution, filesystem state, and OS lookup behaviour. That means procurement, allowlisting, telemetry, and incident response all need to sit in the same control discussion. The practical conclusion is that AI coding agents should be evaluated like high-risk automation platforms, with explicit guardrails for where they run and what they can persist.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• Pivot to control design: Read OWASP NHI Top 10 for the agentic application risks that make runtime governance essential.

What this signals

Runtime resolution hijack is the kind of failure AI programmes will keep rediscovering if they treat agent tooling as an application-layer concern only. The operational response needs to combine endpoint allowlisting, execution-path control, and agent-specific monitoring, because one missed host assumption can undo the rest of the control stack. For teams building governance around agentic AI, this is the point where NIST AI RMF and NIST CSF meet Windows hardening.

The wider signal is that retrieval-augmented or web-connected agents now need identity-style boundaries around what they can read, write, and launch. That makes workload identity, tool-scoped privilege, and file-system governance part of the same conversation. Practitioners should also compare their telemetry coverage with CISA cyber threat advisories and the MITRE ATLAS adversarial AI threat matrix, because prompt injection is now an attack primitive, not a theoretical edge case.

For programmes already piloting coding agents, the decision is no longer whether to adopt them, but where to stop them. The safest pattern is to separate search, write, and execute privileges and force those actions into isolated environments with explicit approval gates. That reduces the chance that a single malicious page can become a host compromise event.

For practitioners

• Restrict AI CLI execution environments Run AI coding agents in isolated devcontainers, WSL instances with limited file access, ephemeral VMs, or cloud development environments instead of on the host OS. Block execution from writable project directories where planted files can influence startup behaviour.
• Audit for runtime hijack artefacts Scan project working directories for unexpected node.bat, node.exe, and node.cmd files after any session that used web search or external content ingestion. Treat those files as indicators of attempted persistence or runtime resolution hijack.
• Disable or constrain web-fed agent workflows Restrict web.run or equivalent retrieval features in sensitive projects and require human approval before an AI agent consumes external pages, writes files, or triggers shell actions. External content should be treated as untrusted input by default.
• Forward AI agent telemetry to the SIEM Monitor process trees, child-process creation, and file writes to execution-sensitive locations such as .vscode, tasks.json, shell rc files, and scheduled task paths. Alert when an AI agent writes to these locations outside a user-initiated change.
• Apply software allowlisting to AI tools Use AppLocker, WDAC, Jamf, or Intune to restrict installation and execution of AI CLI tools to vetted endpoints. Require documented risk acceptance for any tool whose disclosure record or remediation posture is unresolved.

Key takeaways

• This research shows that prompt injection can become host execution when an AI coding agent is allowed to ingest web content and write files.
• The scale of the risk is operational, not theoretical, because the attack depends on common Windows behaviours such as name-based runtime lookup and working-directory precedence.
• Teams should treat AI CLI tools as privileged execution surfaces and pair sandboxing with allowlisting, telemetry, and isolated runtimes.

Key terms

• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads — causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
• Binary Hijacking: Binary hijacking is an attack where a trusted application executes an attacker-controlled file instead of the intended binary. On Windows, this often happens through search-order behaviour, current-directory precedence, or name-based lookup, which makes runtime paths and working directories security-critical.
• Agentic CLI: An agentic CLI is a command-line tool that uses an AI model to choose actions, call tools, and interact with the local environment on a user's behalf. Unlike a chat interface, it can create files, run commands, and influence host state, which requires explicit governance and containment.

What's in the full report

Cymulate's full article covers the exploit chain and validation detail this post intentionally leaves for the source:

• Step-by-step reproduction of the prompt injection and binary hijacking sequence on Windows
• Detailed mitigation advice for node.bat, node.exe, and node.cmd artefacts in project directories
• Control validation guidance for EDR and SIEM teams using the described attack chain
• Disclosure timeline and vendor response context for the reported issue

👉 Cymulate's full post covers the attack chain, disclosure timeline, and mitigation steps in more detail

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, workload identity, and agentic AI identity. It helps security and identity practitioners build the controls that govern delegated access across modern programmes.