cd /news/developer-tools/codex-lands-in-jetbrains-an-in-ide-a… · home topics developer-tools article
[ARTICLE · art-56703] src=dev.to ↗ pub= topic=developer-tools verified=true sentiment=· neutral

Codex lands in JetBrains: an in-IDE agent slot, and less config to babysit

GitHub's Copilot changelog for JetBrains introduces Codex as an agent provider in public preview, alongside ergonomic improvements that move configuration from files and shells into the IDE. The update includes in-IDE management of hooks and MCP servers, admin-configured custom models, and new approval modes for the Claude agent. These changes aim to reduce setup friction and streamline agent behavior control within JetBrains IDEs.

read4 min views1 publishedJul 13, 2026

Last time I set up a coding agent in my IDE, I lost half an hour to a CLI path field and a hooks config living in three different places on disk. If you have wired an agent into JetBrains recently, you know that specific little tax on your morning. So when a fresh Copilot changelog for JetBrains landed, the first thing I looked for was the ergonomics, before I got anywhere near the model list.

GitHub's changelog covers a batch of JetBrains-side changes to the Copilot integration, and most of them move plumbing that used to sit in files and shells into the IDE itself.

The headline is that Codex is now available as an agent provider in public preview. In practice that means it shows up as a slot next to the other Copilot agents, so you can pick it per session instead of switching tools. Setup has one prerequisite worth flagging early: the Codex CLI has to already exist on your machine. In the IDE you then open Settings, Tools, GitHub Copilot, Chat, enable Codex, and point the setting at the Codex CLI path.

Three quieter changes sit alongside it, and these are the ones I expect to actually feel:

.github/mcp.json

.Two more scattered pieces ride in the same release. The Claude agent gained permission mode selection and debug logs. And Copilot CLI approvals now expose three modes inside the IDE: Default Approvals, Bypass Approvals, and an Autopilot preview mode.

If your team writes code in JetBrains and lands it through Copilot-driven review or agent-generated PRs, this reshuffle mostly shortens the loop between "I want to change agent behaviour" and "the agent behaves that way in the next run". Hooks are where you catch or refuse specific tool calls. MCP servers are where you plug in the tools an agent can reach. Moving both into the same editor pane, with real lifecycle controls for MCP, is the kind of thing that turns a Friday afternoon "why did the agent do that" into a Monday morning "here is the rule that stops it doing that again". You will notice it inside the same session that saves you. Admin-configured custom models is the CI adjacency I would not skim past. If a platform team has been the reason JetBrains was second-class inside your org, that reason just got a supported answer, without needing a fork of settings or a shadow doc telling engineers which model to paste into which box.

Public preview is still public preview. Codex-as-agent will move, and features you enable this week may migrate before your muscle memory catches up. The Codex CLI dependency is the specific thing to check before you promise a demo: the IDE is not going to install it for you, and a stale binary is a great way to burn an afternoon. The Autopilot approval mode is explicitly flagged as a preview. Read that word before you flip it on inside a repository you cannot revert cheaply. Bypass and Autopilot are useful shapes, and they are also a paved road to an agent doing something you did not read closely. Start with Default Approvals, watch what the agent actually asks for, and only move the dial after you have seen the same ask twice.

Hooks and MCP living in the same editor pane is a real ergonomic win. It is also more surface area for drift between engineers on the same team. If two people configure hooks in-IDE without ever checking .github/mcp.json

into the repo, you will end up with agents that behave differently for different humans. The workspace-level file is the correct answer here. Put it under source control on day one, and review it in the same PR that ships the change.

Two things. First, whether "Codex as agent provider" evolves into a general provider shape or stays specific to Codex; the picker only gets useful when its entries are stable enough to reason about across sessions. Second, whether the hook and MCP UI grows a diff view against what the repo has committed, so a teammate can spot when a colleague's local Copilot has quietly drifted from the shared config. That is the small feature I would trade a lot of louder releases for.

Try the changelog on a scratch repo before you touch a real one. Then tell me if the Codex CLI dance was worth it.

── more in #developer-tools 4 stories · sorted by recency
── more on @github 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
Live at https://your-agent.zahid.host
Get free account → Pricing
from €0/mo · no card required
LIVE [news/codex-lands-in-jetbr…] indexed:0 read:4min 2026-07-13 ·