Coding Agents Driving Local Apps: The Security Question Behind the Blender Demo

Developer Simon Willison published a short write-up this week describing how he pointed ChatGPT Codex at the full Blender desktop application on macOS. A single prompt told Codex to "use the already install /Applications/Blender to render a scene of a pelican riding a bicycle"; two follow-up prompts asked it to add a background and "a lot of flair," then to make the result "a whole lot better." (Using Blender with coding agents on macOS)

What actually happened

Codex didn't generate a static image from a prompt. It drove Blender's own Python API — the same scripting interface a human artist would use inside the application — to build a scene, iterate on it across three separate turns, and render the output. There was no custom integration code and no Blender-specific plugin involved: the agent located an installed application on disk and worked out how to script it toward a goal that kept changing with each prompt.

Why this is a security question, not just a fun demo

To do this, an agent needs to locate and execute a separate, fully-privileged desktop application by file path, then drive that application's own automation surface — not merely edit text or run a scoped shell command inside a repository. That is a meaningfully larger capability than the file-editing and command-running most people picture when they hear "coding agent," and it matters as soon as the same agent is exposed to untrusted input: a fetched web page, an email attachment, a ticket description, or a repository it was asked to review. If any of that untrusted content can influence what the agent decides to launch or script, the effective blast radius is whatever installed application it can find on the machine — not just the current git worktree.

The permission model most coding agents actually ship with

OpenAI's documentation for Codex describes a tiered approval system built around the working directory and the network. By default Codex runs in workspace-write mode with on-request approvals: it can read files, make edits, and run commands inside the working directory automatically; .git, .agents, and .codex directories stay read-only; network access is off unless explicitly enabled; and anything that edits files outside the workspace or needs network access triggers an approval prompt (Agent approvals & security, OpenAI). That model is designed around "files in this repo" and "the internet" as the two things worth gating — it doesn't speak to a workspace-scoped agent invoking an entirely separate, already-installed GUI application and driving it through its own API, which is exactly what the Blender demo does. Willison's post doesn't state which sandbox or approval mode he was running under, and that gap is itself worth noting: it's precisely the question a demo like this raises but doesn't answer.

What this means for engineering and security leaders

• Inventory what local applications, interpreters, and scripting APIs a coding agent's host machine can actually reach — the repository is not the real boundary once an agent can shell out to /Applications or a local binary.
• Treat "launch and script an installed application" as its own capability grant, reviewed the way you'd review shell or network access, rather than assuming it's already covered by workspace or file-write policy.
• Before enabling agentic coding tools on developer laptops, confirm the actual default approval mode in use (on-request, never, or something more permissive) rather than the mode you assume is set.
• Fold new local-execution capabilities granted to agents into existing AI-governance change control (ISO 42001-style processes) instead of treating them as routine tooling updates.

FAQ