Ben Potter

Product Manager

<p><a href="https://developers.openai.com/codex">OpenAI Codex</a> has evolved into a suite of agentic software development and business tools, but it has one problem: users are confined to either running workloads directly on their laptops or on OpenAI’s cloud environments.</p>

<p>For regulated enterprises (or those with complex development environments), this effectively becomes a non-starter for widespread adoption. While some power-users can be trusted to run these workloads on laptops, the security risks (prompt injection, code exfiltration, data loss) of running locally are too high. On the other hand, OpenAI’s cloud environments are limited to running a single container per repository and lack connectivity to internal enterprise networks. </p>

<p>The Codex agent itself is extremely capable and powerful, but there is not a proper environment to run them on with all of the proper context, security, and tooling. </p>

<h1>Enter Coder</h1>

<p>Coder runs governed developer environments on remote infrastructure, off laptops, centralized and hardened by your platform team. Unlike OpenAI&#39;s cloud environments, Coder workspaces run entirely on your infrastructure and aren&#39;t limited to a single container per repository. Defined in Terraform, Coder workspaces can run containers, full VMs, or anything else your stack requires, on your infrastructure, inside your network, with access to your internal services, your secrets management, your CI systems, and whatever else your developers actually need to do their jobs.</p>

<p>Workspaces come with your repositories checked out, dependencies installed, and the context Codex needs to do useful work from the moment it starts. Developers connect via browser or IDE.  Codex is already there, authenticated, and configured the way your platform team decided. No local installs, no manual configuration, no API keys in dotfiles.</p>

<p>For Codex, the workspace is the sandbox. Firewall rules, network configuration, identity, and auditing are all handled centrally. You can run full-auto mode without the risks of doing it locally, because the workspace is isolated infrastructure your platform team controls. Not a laptop with a home directory full of credentials.</p>


Set Up OpenAI Codex in Coder: Self-Hosted AI Coding Agent Tutorial

<h2>Reference architecture</h2>

<p>Coder can be deployed in a number of different ways, but the most common pattern we see from customers is AWS with EKS and Coder running on their VPC. For Codex specifically, the timing is good: Codex is now available directly on Amazon Bedrock, meaning customers running Coder on AWS can hit Codex through the same Bedrock APIs and controls they already use. No OpenAI API proxy, no separate key management story, and no new vendor relationship to manage.</p>

<p>Codex workspaces sit behind the same network controls as everything else in that environment: egress is filtered, ingress is controlled, and the API key the agent uses is injected by the template, not typed in by the developer.</p>

<p><img src="https://www.datocms-assets.com/19109/1783028637-open-ai-codex-coder.png" alt=""></p>

<p>For organizations not on AWS, Coder runs on Azure, GCP, VMware, OpenShift, and on-prem. Around 40% of our customers run something other than AWS with EKS. The architecture is the same regardless: Coder&#39;s control plane manages provisioning, the workspace is where Codex runs, and the client machine stays clean.</p>

<p>See our <a href="https://coder.com/docs/install/kubernetes">guides for installing Coder on Kubernetes</a>.</p>

<h2>Coder templates: the golden path in practice</h2>

<p>Templates are written by platform administrators and define the underlying infrastructure, dependencies, and tools for developer environments. Users pick a template from a curated list to get into a workspace.</p>

<p>For most organizations, a single &quot;golden template&quot; covers the main population of users: a developer making a quick change, a product manager prototyping something, a QA engineer writing tests. That template has the languages, utilities, and tooling the team needs pre-installed and pre-configured. Codex included.</p>

<p>Organizations with different needs can run multiple templates. A stricter template for contractors might scope Codex to a single repository. A broader one for senior engineers might have wider network access and full-auto enabled by default. Same platform, same governance, different postures. These decisions live in the template, managed by the platform team, not scattered across individual developer machines in dotfiles and shell configs nobody has audited.</p>

<p>Because Coder is language and tooling agnostic, the same platform that runs your Codex environments also runs environments for teams that don&#39;t use Codex at all. Python, Java, Go, whatever the stack. The golden path isn&#39;t opinionated about what you build or what tools you use. It&#39;s opinionated about how environments are provisioned, secured, and managed.</p>

<p>See our <a href="https://coder.com/docs/admin/templates">guides for template management</a>.</p>

<h2>AI governance</h2>

<p>Coder handles sandboxing and network controls. But that only stops agents from doing dangerous things in the moment. It doesn&#39;t tell you what the agent did, who ran it, which model it talked to, which MCP servers it called, what files it wrote to, or whether the configuration it ran under matched what your security team actually approved.</p>

<p>Different teams running different versions, different API keys pointed at different endpoints, none of it logged anywhere. When something goes wrong, or when legal asks what the agent did last Tuesday, there&#39;s no answer.</p>

<p>Coder&#39;s AI Governance Add-On handles this at the platform level. Every Codex session is fully audited and visible in the Sessions UI. Those logs can be ingested into your SIEM for storage and analysis. The configuration governing what the agent can do, which model endpoint it hits, how environment variables are handled, lives in the template. Not in a config file on someone&#39;s laptop that may or may not match what everyone else is running.</p>

<p>Learn about <a href="https://coder.com/docs/ai-coder/ai-governance">AI Governance with Coder</a>.</p>

<h2>Looking forward</h2>

<p>Codex started as a terminal agent. It has since expanded well beyond software developers, with knowledge workers now making up roughly one in five users and growing at more than triple the rate of the core developer group. Today, <a href="https://openai.com/index/openai-to-acquire-ona/">OpenAI announced the acquisition of Ona</a>, bringing its secure cloud execution and orchestration technology into the Codex ecosystem to handle longer-running work across hours or days. Codex is becoming a platform. </p>

<p>We&#39;d like to see OpenAI take the same path <a href="https://cursor.com/blog/self-hosted-cloud-agents">Cursor did with self-hosted cloud agents</a>: let enterprises run Codex&#39;s agentic workflows on their own infrastructure. Regulated organizations can&#39;t send code, secrets, or build artifacts to a third-party cloud. A single container per repository doesn&#39;t reflect how real development environments work. </p>

<p>Self-hosting support would let the full Codex experience, the IDE extensions, the background agents run on Coder or any trusted enterprise infrastructure. Until then, the Codex CLI works great in Coder today. </p>

<hr>

<p><strong>Get started</strong></p>

<p>You can learn how to install <a href="https://coder.com/docs/install">Coder Community Edition</a> (or start a <a href="https://coder.com/trial">premium trial</a>) and have Codex running in a governed workspace in minutes. For a deeper look at how Coder fits your infrastructure, reach out to our technical sales team at <a href="mailto:sales@coder.com">sales@coder.com</a>.</p>


Run OpenAI Codex in self-hosted cloud development environments built for regulated enterprises. See how Coder secures AI coding agents at scale.

How To Set Up Enterprise Development Environments with OpenAI Codex and Coder

Dave Ahr

Staff Sales Engineer

<p>Kiro CLI is a strong terminal coding agent, but like any agent, it is risky to run on a local laptop. From a security standpoint, the agent can read your local files, run commands as you, and reach the internet. That gives it room to take actions on your behalf, delete files, read credentials, or send data somewhere it shouldn&#39;t go.</p>

<p>The risk is higher for the people who often get the most out of an agent: product managers, QA engineers, and data scientists who aren&#39;t steeped in sandboxing and least-privilege practices and tend to hand riskier work to the agent.</p>

<p>Kiro CLI raises the stakes because it is built for autonomy. It descends from the Amazon Q Developer CLI, runs subagents in parallel, fires hooks on events, and can run non-interactively inside a pipeline with an API key. Approving each tool call by hand defeats the point, but turning approvals off on a laptop full of sensitive code and open network access is exactly the setup you want to avoid.</p>

<p>Because of this, many IT and security teams block terminal agents on the desktop, or limit them to a small group of engineers who can manage the risk. There is a better place to run them.</p>


How to Run Kiro CLI Securely in Coder Workspaces (Setup & Demo)

<h2>Enter Coder</h2>

<p>Coder runs developer environments on remote infrastructure managed by your platform team. Instead of working on a laptop, developers connect to workspaces running in your cloud or datacenter. Nobody installs Kiro CLI locally or manages their own keys and MCP config. The workspace comes pre-built with the agent, the right tooling, and the network and identity controls your organization requires.</p>

<p>This changes how you think about autonomy. Inside a Coder workspace you can let the agent run its tools without hand-approval, because the blast radius is a disposable, network-isolated environment rather than a personal machine. If something goes wrong, you delete the workspace and start a new one.</p>

<h2>Reference architecture</h2>

<p>Coder can be deployed in many ways. Here is a common pattern for running Kiro CLI.</p>

<p><img src="https://www.datocms-assets.com/19109/1782424016-blog_coder-kiro-graphic1.png" alt=""></p>

<h3>Infrastructure</h3>

<p>Coder is self-hosted and runs on any cloud or on-premise datacenter. The most common setup is AWS with EKS, which lets you scale to thousands of workspaces for people and agents. Running on your own VPC keeps ingress and egress under your control and lets workspaces reach internal services like source control and CI.</p>

<p>There is a useful detail for Kiro here. Kiro routes its model inference through its own managed backend, which runs in AWS regions (currently us-east-1 and eu-central-1). If your Coder deployment is already in AWS, both the workspace and the model traffic stay inside AWS&#39;s network. That matters for AWS-aligned and public sector teams, and Kiro supports IAM Identity Center and AWS GovCloud (US) for authentication.</p>

<h3>Templates</h3>

<p>Templates are written by platform admins and define the infrastructure and tools behind each workspace. A common approach is a golden template with the languages and utilities most people need (Java, Python, git, jq) plus the agent itself. Kiro CLI installs with a single Terraform module, which can be found in the <a href="https://registry.coder.com/modules/harleylrn/kiro-cli">Coder Registry</a>:</p>

<pre><code>module &quot;kiro-cli&quot; {
  count    = data.coder_workspace.me.start_count
  source   = &quot;registry.coder.com/harleylrn/kiro-cli/coder&quot;
  version  = &quot;1.0.1&quot;
  agent_id = coder_agent.main.id
  workdir  = local.work_folder

  install_agentapi = false
  report_tasks     = false
}
</code></pre>

<p>You bake the agent&#39;s steering files and approved MCP servers into the template too, so every workspace starts with the same context and the same tools. For non-developers, you can ship a locked-down template variant with a hardened VPC and limited network access, aimed at people who just need the agent for prototyping</p>

<p>By default, the Kiro CLI Terminal UI prompts for shell approval every session, even when using a Coder module to install it. On a laptop, approving each command is a reasonable safeguard, since the agent is running next to your real files and credentials. In a Coder workspace that reasoning no longer applies. The agent runs in an isolated environment with the network limits you set, and if something goes wrong you delete the workspace and rebuild it. At that point the prompt only gets in the way.</p>

<p>The root cause is subtle: Kiro&#39;s active agent config (<code>~/.kiro/agents/agent.json</code>) separates tool <em>availability</em> from tool <em>trust</em>. The <code>tools</code> array defines what the agent can access, while <code>allowedTools</code> controls what runs without prompting. The h<code>arleylrn/kiro-cli</code> Coder module writes this file at workspace startup with <code>shell</code> in <code>tools</code> but not in <code>allowedTools</code>, so every shell command still requires manual approval. The fix is a companion <code>coder_script</code> resource that waits for the module to finish writing <code>agent.json</code>, then uses <code>jq</code> to add &quot;<code>shell</code>&quot; to <code>allowedTools</code> without overwriting the rest of the module-managed config. The idempotency check ensures the patch applies cleanly on workspace restarts and prebuild runs without duplicating the entry.</p>

<pre><code>resource &quot;coder_script&quot; &quot;kiro_agent_config&quot; {
  agent_id     = coder_agent.main.id
  display_name = &quot;Kiro CLI Agent Config&quot;
  icon         = &quot;/icon/kiro.svg&quot;
  run_on_start = true
  script       = &lt;&lt;-EOT
    # Wait for the module to write agent.json first
    until [ -f ~/.kiro/agents/agent.json ]; do sleep 2; done

   # Add shell to allowedTools if not already present
    if ! jq -e &#39;.allowedTools | contains([&quot;shell&quot;])&#39; ~/.kiro/agents/agent.json &gt; /dev/null 2&gt;&amp;1; then
      jq &#39;.allowedTools += [&quot;shell&quot;]&#39; ~/.kiro/agents/agent.json &gt; /tmp/agent.tmp \
        &amp;&amp; mv /tmp/agent.tmp ~/.kiro/agents/agent.json
    fi
  EOT
}
</code></pre>

<p>Additionally, The kiro-cli does not support headless authentication.  So, there must be a human in the loop.  This can be done in a few ways:  First, you can pre-generate an authentication tarball on a machine where you&#39;ve already authenticated, second, you can authenticate using the Kiro CLI from the workspace dashboard or you can authenticate from inside the workspace itself through the VSCode terminal.  The authentication tarball can be an optional parameter baked into the template.</p>

<p>Add a coder_parameter for the tarball and wire it into the module. Parameters with default = &quot;&quot; and mutable = true let the user optionally paste their tarball at workspace creation (or edit later).</p>

<pre><code>data &quot;coder_parameter&quot; &quot;kiro_cli_auth_tarball&quot; {
  name         = &quot;kiro_cli_auth_tarball&quot;
  display_name = &quot;Kiro CLI auth tarball (optional)&quot;
  description  = &lt;&lt;-EOT
    Paste a base64+zstd encoded Kiro CLI auth tarball to         pre-authenticate the CLI.

    To generate one, on a machine where you&#39;ve already run `kiro-cli login`:

        cd ~/.local/share/kiro-cli &amp;&amp; tar -c . | zstd | base64 -w 0

    Leave blank to skip; you can authenticate inside the workspace by running `kiro-cli login`.
  EOT

  type         = &quot;string&quot;
  form_type    = &quot;textarea&quot;
  mutable      = true
  default      = &quot;&quot;
  order        = 50
}
</code></pre>

<p>Wire it into the module:</p>

<pre><code>module &quot;kiro-cli&quot; {
  count    = data.coder_workspace.me.start_count
  source   = &quot;registry.coder.com/harleylrn/kiro-cli/coder&quot;
  version  = &quot;1.0.1&quot;
  agent_id = coder_agent.main.id
  workdir  = local.work_folder

  install_agentapi = false
  report_tasks     = false

  auth_tarball = data.coder_parameter.kiro_cli_auth_tarball.value
}
</code></pre>

<p>The module&#39;s install script extracts the tarball with <code>tar -I zstd</code>. Your Coder image may or may not have <code>zstd</code> installed. If extraction fails with &quot;<code>zstd: command not found</code>&quot;, add a <code>pre_install_script</code> to install it, but since this image runs as a non-root user with <code>no_new_privs</code>, you can&#39;t apt-get install. Two options:</p>

<ol>
<li>Bake <code>zstd</code> into the image (preferred for production).<br></li>
<li>Use a statically-compiled <code>zstd</code> binary in <code>~/.local/bin</code>:</li>
</ol>

<pre><code class="shell">pre_install_script = &lt;&lt;-EOT
  if ! command -v zstd &gt;/dev/null 2&gt;&amp;1; then
    mkdir -p $HOME/.local/bin
    curl -fsSL -o $HOME/.local/bin/zstd \
      https://github.com/facebook/zstd/releases/download/v1.5.6/zstd-1.5.6-linux-x86_64
    chmod +x $HOME/.local/bin/zstd
    export PATH=&quot;$HOME/.local/bin:$PATH&quot;
  fi
EOT

(That URL is illustrative — check the latest zstd release for a static Linux binary. Many distros include zstd already, so try without this first.)
</code></pre>

<h3>The agent</h3>

<p>Kiro CLI gives you custom agents with scoped tool permissions, steering files for team conventions, native MCP support over stdio and HTTP, hooks, a planning mode that explores changes without touching code, and a headless mode for automation. In a Coder workspace, all of that runs inside the isolation and network boundary you set.</p>

<p>One thing to know up front: Kiro&#39;s model calls go to Kiro&#39;s managed inference and are billed in credits against your subscription, rather than through an API key you hold. You don&#39;t hand the workspace an Anthropic or Bedrock key to manage. That shapes how you govern the AI layer, which we&#39;ll cover below.</p>

<h2>How it works</h2>

<h3>Creating a workspace</h3>

<p>A developer logs into your Coder instance and picks the Kiro template along with any parameters the admin exposes. The workspace comes up with the agent, dependencies, repositories, and controls already in place.</p>

<p><img src="https://www.datocms-assets.com/19109/1782424122-blog_coder-kiro-graphic2.png" alt=""></p>

<h3>Connecting from the VSCode terminal</h3>

<p>Once the workspace is provisioned, launch your local VSCode Desktop from the workspace dashboard:</p>

<p><img src="https://www.datocms-assets.com/19109/1782424154-blog_coder-kiro-graphic3.png" alt=""></p>

<p>Open the workspace terminal in VSCode and run:</p>

<pre><code class="shell">kiro-cli
</code></pre>

<p>Because a workspace is a remote, headless machine, signing in uses Kiro&#39;s device flow. The CLI prints a URL and a one-time code. You open the URL in any browser and enter or approve the code, and the CLI picks up the session. No port forwarding or tunnel setup. For automation, you can authenticate with a KIRO_API_KEY and run the CLI non-interactively instead. API keys are available on paid tiers and can be governed by your Kiro admin.</p>

<p><img src="https://www.datocms-assets.com/19109/1782424185-blog_coder-kiro-graphic4.png" alt=""></p>

<h2>Governing Kiro</h2>

<p>Governance for Kiro on Coder splits across two layers, and it helps to be clear about which system owns what.</p>

<p>Coder governs the environment. Workspaces are isolated from each other, egress is filtered at the VPC and workspace level, identity flows into the workspace through your provider, and workspace activity is audited. This is where you contain what the agent can reach and do.</p>

<p>Kiro&#39;s enterprise console governs the AI layer. From the console, admins can control which models users may select and set a default, govern which MCP servers and web tools are allowed, manage whether users can create API keys, and monitor usage. Authentication supports SSO through IAM Identity Center.</p>

<p>Together these cover the environment and the model-and-tools layer. The one gap to set expectations on is per-prompt and per-token capture, which leads to the question we get asked most often.</p>

<h2>Can you route Kiro through an AI Gateway?</h2>

<p>Short answer: not today.</p>

<p>Coder&#39;s AI Gateway, part of the AI Governance Add-On, works as a proxy between an agent and providers like Anthropic and OpenAI. The agent sends its API calls to a Coder endpoint, authenticates with a Coder token, and Coder forwards the request to the provider. Because it sits in the middle of that traffic, the gateway can record prompts, token usage, and tool calls, and it can inject an approved set of MCP tools.</p>

<p>For that to work, the agent has to let you point its inference at a custom endpoint and authenticate with a custom token. Kiro CLI does not expose either. Its model calls go to Kiro&#39;s managed backend using Kiro&#39;s own authentication, so there is no endpoint to redirect and no provider key to route. The same applies to LiteLLM, which also needs the client to target its proxy with an OpenAI or Anthropic-compatible endpoint. Also tool injection happens on traffic that passes through the gateway, you can&#39;t inject MCP tools into Kiro through it either.</p>

<p>So you govern Kiro&#39;s AI layer in Kiro&#39;s console (models, MCP servers, web tools, and usage), and you use Coder for the environment and network controls around it. If Kiro adds support for a configurable inference endpoint and credentials in the future, the AI Gateway is ready to sit in front of it. The pattern holds either way: the environment is the constant, and the agent is the variable.</p>

<h2>Looking forward</h2>

<p>The bigger shift is running many agents at once. Because Coder workspaces are quick to create and pre-hardened, the same template that gives one developer a Kiro environment can back a fleet of headless agents, each in its own isolated workspace, working through pull request reviews, documentation updates, or a modernization backlog. The governance and network boundary you defined apply to every one of them. Running a group of autonomous agents stops being a power-user trick and becomes a normal way to work.</p>

<h2>How to get started</h2>

<p>You can install Coder Community Edition or start a premium trial and have Kiro CLI running in a governed workspace quickly. Add the install script along with your MCP and steering config to a template, and your team picks it from the list. For a closer look at how Coder fits your infrastructure, reach out to our technical sales team.</p>


Run Kiro CLI safely on enterprise infrastructure with Coder workspaces. Get full agent autonomy without the security risk of running terminal agents on laptops.

Using Kiro CLI with Coder Workspaces

Nicky Pike

Field CTO at Coder and host of the [Dev]olution podcast

Being a Coder Means Being a Problem Solver

<p>DaShaun Carter has run the same live demo for years. He upgrades a Spring project in front of an audience and watches the CVE count drop from 290-something to zero. He&#39;s done it so many times that he&#39;s caught brand-new Spring Boot releases mid-demo, before the announcement post even went live. The patch ships before the blog does, and his automation finds it first.</p>

<p>But a couple weeks before we recorded an episode for the <a href="https://www.youtube.com/@Devolution-Podcast">[Dev]olution Podcast</a>, the demo stopped at four.</p>

<p>First time that ever happened. And the four weren&#39;t Spring&#39;s. They were days-old vulnerabilities in third-party libraries riding along in the dependency tree, the part of your software nobody&#39;s watching closely enough.</p>

<p>Here&#39;s the math that should bother you. <a href="https://www.bitsight.com/press-releases/bitsight-reveals-more-60-percent-known-exploited-vulnerabilities-remain-unmitigated">Bitsight</a> pegs remediation for a critical vulnerability at about four and a half months on average, and known-exploited vulnerabilities overall closer to six. Pick whichever number you like; it&#39;s measured in months. Meanwhile, <a href="https://www.vulncheck.com/blog/exploitation-trends-q1-2025">VulnCheck</a> found that 28.3% of exploited vulnerabilities got weaponized within 24 hours of disclosure. Months on defense. A day on offense.</p>

<p>That math doesn&#39;t math.</p>

<p>And if your plan still leans on severity scores, DaShaun has bad news there too. Attackers are chaining a CVSS 1 with a CVSS 3, splitting the payload across both, and walking right past tooling that only watches for the scary nines. &quot;It&#39;s just a three, we&#39;re not at risk&quot; stopped being a sentence you get to say out loud.</p>

<p>Full disclosure: I owe DaShaun a personal debt, so I take his patching opinions seriously. Back when Nick Kuhn and I were busy planning Cloud Foundry Weekly to death, DaShaun opened his laptop and booked our first live episode for the following week. &quot;Just jump in, you&#39;ll figure it out.&quot; He was right. He&#39;s been living his own advice since around 2000, when a server he forgot to patch got hacked back in his web-hosting days. He&#39;s been obsessive ever since. He calls it the N-minus-zero life: latest version of everything, always, no exceptions.</p>

<p>So what&#39;s his fix for the five-month problem? That&#39;s the back half of the episode, and it&#39;s worth the watch precisely because it isn&#39;t &quot;patch faster,&quot; and it isn&#39;t &quot;turn an AI agent loose on your repos&quot; either. DaShaun runs agents that never write a single patch. His argument: the second you let AI freelance a fix per repo, you lose determinism, and determinism is the only thing that survives contact with a thousand repositories. (<a href="https://youtu.be/kqFP-9A4Vb8?t=2039">He lays out the recipe model around 33:59.</a>) </p>

<p>Also on the table: why a guy who spent years making fun of banks for keeping code off developer laptops now refuses to bank anywhere that doesn&#39;t, and what a 104-node Raspberry Pi cluster has to do with your enterprise AI budget.</p>

<p><a href="https://youtu.be/kqFP-9A4Vb8"><strong>Watch the full episode on YouTube</strong></a></p>

<p>If continuous patching, six-figure agent bills, and a grown man touring the country with a Raspberry Pi army sound like your kind of conversation, subscribe. New episode every two weeks.  </p>


DaShaun Carter's upgrade demo always lands at zero CVEs. Two weeks ago it stopped at four, and what that means should worry every enterprise.

Five Months to Patch, One Day to Weaponize: CVE Remediation Has a Math Problem

Discover the latest at the official Coder blog: updates, company insights & AI development infrastructure tips for enhanced developer productivity.

How To Set Up Enterprise Development Environments with OpenAI Codex and Coder

Using Kiro CLI with Coder Workspaces

Five Months to Patch, One Day to Weaponize: CVE Remediation Has a Math Problem

All posts