The IDE where I noticed
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.
What actually shipped
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:
- Hooks in the Customizations editor. Hooks can now be managed inside Agent Customizations, in both local and Copilot CLI sessions. One less place to keep in sync when a hook needs a tweak mid-flow.
-
In-editor MCP server management. Under Agent Customizations for Copilot CLI sessions you can browse a marketplace or add a server directly, choose the command or HTTP transport, and start, stop, restart or uninstall a server from the same screen. Workspace-level MCP config is read from
.github/mcp.json. - Admin-configured custom models. Copilot for JetBrains now honours custom models that a Copilot Business or Enterprise administrator has configured in GitHub settings. If your org has been holding back on JetBrains because model choice was managed off-IDE, the picker now respects the org policy.
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.
Why it matters for a CI-adjacent workflow
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.
The rough edges I would watch
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.
What I am watching next
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.
Top comments (0)