So I- I was actually setting up a new workspace yesterday, and,
uh, you know that sheer, absolute dread when you realize you have to migrate all
your developer tools?
Like, copy-pasting API keys, manually re-registering all your MCP servers...
it is just a, a massive chore.
But, before we dive into how to fix that, a quick shout-out to Jellypod for
supporting the show.
Now, with Codex CLI version 0.145.0, they- they actually introduced this
expanded /import command that basically tries to solve this entire onboarding
nightmare in a single keystroke.
Oh, the onboarding nightmare is so real.
As a tester, I- I used to spend hours just trying to replicate a bug on a clean
machine because of some tiny, hidden config file.
So, this /import command, what is it actually grabbing?
Is it just pulling in basic key-value pairs, or is it, like,
actually digging into the system?
It's- it's surprisingly aggressive.
It literally crawls your file system to find where your other tools live.
So, if you're on a Mac, it- it programmatically scans ~/Library/Application
Support/Cursor/User/settings.json.
Or, um, if you're on Windows, it goes straight for
%APPDATA%\Cursor.
And for Claude Code, it searches that
~/.config/@anthropic-ai/claude-code/config.json
path.
It is looking for your custom prompts, your active extensions,
even your system preferences, and just pulling them right in.
Wait, so it's sniffing out the exact claude-code/config.json path?
That's...
I mean, that is a direct shot at Anthropic.
But, okay, settings are one thing.
What about the actual tools?
Like, if I have Model Context Protocol-you know, MCP servers set up to query my
local databases or run custom scripts-does /import actually migrate those too?
Yeah, that- that was the part that kind of blew me away.
It doesn't just copy them; it- it translates them.
It parses the third-party MCP definitions-like, the transport types,
the arguments, the custom environment variables-and converts them into the
Rust-native format that Codex uses, which lives in
~/.codex/config.toml.
So if you have a local PostgreSQL MCP server, it just...
works.
You don't have to reconfigure the connection strings or anything.
Huh.
A local PostgreSQL connector just migrating automatically...
that sounds almost too easy.
But wait, what about the actual context?
Like, Claude Code has these project-specific memories and rules it builds up over
time.
If I switch to Codex, do I- do I lose all that progress, or is /import touching
those too?
It actually ingests those project-scoped memories!
It reads the existing rules and injects them directly into Codex's experimental
paginated thread history.
So, those- those persistent memories you've spent weeks tuning?
They get carried over into Codex's memory system so the AI agent doesn't suddenly
forget your project's architectural quirks on day one.
Okay, but as someone who spent years breaking software, my "spidey-sense" is
tingling.
There is no way an automated import script can bypass everything.
What's the- what's the catch here?
What does it actually fail to import?
You nailed it.
There are some- some pretty hard boundaries, mostly because of OS-level sandboxing.
Codex cannot read secure Cursor session tokens or Claude API keys from your system
keychain.
The OS just blocks it.
So, you still have to do a one-time manual authentication after you run /import.
And, uh, if you have absolute file paths hardcoded in your imported shell commands,
those will break if you aren't running Codex from the exact same workspace root
directory.
Right, because absolute paths are the bane of every developer's existence when they
move to a new environment.
But, speaking of things breaking, let's talk about performance.
In the older versions, if one of your local MCP servers was offline-say,
a local Docker container or a sluggish Jira server-the whole CLI would just hang on
startup.
Did they address that in 0.145.0?
Yes!
And honestly, this bug was infuriating.
It used to block the entire startup sequence.
Now, they've implemented strict startup timeouts and serialized the OAuth refresh
loops.
So if your local Jira MCP server is completely unresponsive,
Codex doesn't care.
It just starts up instantly in the background and lets you keep coding,
rather than making you sit there staring at a frozen terminal.
Oh thank goodness.
There's nothing worse than a tool blocking you from typing just because some
third-party API is having a bad day.
Speaking of the terminal, did they do anything about that horrible screen flicker?
Whenever I'd stream a massive code change, like a 400-line Rust diff,
my terminal would just go wild, redrawing the entire screen and making my CPU fan
sound like a jet engine.
Oh, the- the terminal flicker was terrible.
Yes, they completely overhauled the rendering engine.
They're now using incremental stream buffering with hard bounds on terminal output.
So, instead of redrawing the entire active screen every time a new line of code
streams in, it- it only updates the specific characters that changed.
It's incredibly smooth now, even for those massive 400-line diffs.
That is a huge quality-of-life win.
But, looking at the bigger picture here...
this aggressive /import feature.
It really makes me wonder where the developer tool space is going.
I mean, are we going to see an industry-standard configuration format for AI agents
eventually, or is this just OpenAI making a highly aggressive move to lower the
switching cost and poach Cursor and Claude users?
It's a great question.
I mean, we might see a standard format emerge, but right now,
it feels like an onboarding war.
If you can steal your competitor's entire configuration with a single command,
why wouldn't you?
It makes switching to Codex almost entirely frictionless.
Anyway, that's- that's all the time we have for this quick take.
Thanks for listening, and we'll talk to you next time.
See ya!