Make Codex Boost Your Terminal Startup Speed by 10x

Recently I decided to replace Oh My Zsh, which I’ve used for years, with a modern lightweight setup: Zinit + Starship + Rust toolchain (eza/bat/fzf/zoxide).

But instead of painstakingly typing everything myself, I simply threw the entire design document at Codex and let it handle the migration, tuning, and verification on my real macOS environment. The whole process revealed an interesting point: the difference between an agent doing work and a human doing work isn’t about knowing how to write configurations—it’s about whether you set up “verification checkpoints” at every step.

First, the current situation assessment

The problem with Oh My Zsh isn’t that its plugins are bad—it’s that it loads a ton of unnecessary stuff every time a shell starts. The half-second delay was something everyone tolerated as “the cost of doing business,” but nowadays more and more people can’t stand it anymore.

The core idea of the new camp is to switch to on-demand loading:

The goal was to compress startup time from OMZ’s hundreds of milliseconds down to under 120ms.

How Codex handled it

I sent the design doc with just this one sentence: “Use Zinit’s lazy-load to replace Oh My Zsh’s full load, keep the git aliases you actually use from OMZ, add the Rust toolchain feel**.” Then I added: “Help me configure my current shell environment—I’m using oh my zsh—delete OMZ directly and enable this form.” What happened next was more “engineering-heavy” than I expected:

1. Back up first, then act. Instead of directly overwriting ~/.zshrc, it first confirmed that my current config, besides OMZ, also included mise, Bun, pnpm, DYLD_LIBRARY_PATH, and several API key exports. These were “existing assets” that had to be preserved intact—they couldn’t be accidentally deleted during the framework migration.

2. Extract secrets from the main config. It moved all secret-key exports into a separate ~/.zshrc.local, and the main config only sources it. This action wasn’t in the design document—it was something Codex decided to add on its own, judging that “framework config and secrets shouldn’t be mixed together.”

3. Syntax check before deletion. After writing the new config, it first ran a syntax check to confirm the Starship config could be parsed correctly by the current version, then executed the irreversible operations of backup, writing, and OMZ deletion.

4. The validation environment itself might be lying. During the first round of speed tests, the “pseudo-interactive” environment zsh -i -c threw ZLE-related errors and unrealistically slow times (with network wait from the first-time plugin downloads). It didn’t treat these noise as real problems to “optimize away”—instead, it first identified the noise source, distinguishing between “is this a problem that will happen in a real terminal?” and “is this just an artifact of the test method itself?” Eventually it pinpointed that fzf --zsh was trying to bind keybindings in a non-TTY environment, so it added a condition to only load in real terminal sessions, rather than simply cutting features to get a prettier test number.

5. Use profiling instead of guessing. When optimization stalled at 0.27s, it didn’t keep tuning by gut feeling—it wrapped in zprof and measured that Zinit’s OMZ snippets took about 20ms, compinit about 13ms, and mise’s initialization (which forks a subprocess every time) was the biggest chunk at about 70ms via mise activate zsh --shims.

6. Targeted fixes, not blanket lazy loading. After finding the bottleneck, it changed several ZLE-related plugins (fzf-tab, autosuggestions, syntax-highlighting) and OMZ snippets to use Zinit’s turbo delayed loading—ensuring the prompt appears first, then functional plugins load transparently afterwards. For mise, it didn’t simply delay it—it directly replaced it with a zero-fork PATH injection method, skipping the entire subprocess overhead.

What this tells us

In the end, the migration didn’t precisely hit the 120ms target (the median bounced between 0.27s–0.66s), but compared to OMZ’s original experience, it was already an order-of-magnitude improvement. More than the final number, I care about these specific actions during the process:

• Before irreversible operations (deleting OMZ), always back up and verify first
• When you measure a “problem,” first suspect whether the test method itself is flawed, instead of rushing to optimize
• When stuck, use a profiling tool instead of continuing to tune by feel
• Optimization must be contextual—delay loading where appropriate, change implementation where appropriate, not a one-size-fits-all approach

This “engineering discipline” used to require experience accumulation. Now when Codex handles tasks like configuration migration, it already takes these as default actions. For independent developers, this means many tedious chores where “I know what to do but can’t be bothered to be careful at every step” can be confidently handed off.

Appendix: The exact words I gave to Codex

Use Zinit’s lazy-load to replace Oh My Zsh’s full load, keep the git aliases you actually use from OMZ, add the Rust toolchain feel**. The migration path is smooth—preserve muscle memory, remove extra overhead, use zinit snippet OMZP::git and similar methods to on-demand introduce OMZ plugins. If you’re currently using Oh My Zsh, you can directly replace it with this scheme without uninstalling OMZ first. If you want me to adjust aliases or Starship display content based on your specific Node/Go/Podwise workflow, just say so. Help me configure my current shell environment according to the above scheme—I’m using oh my zsh—delete OMZ directly and enable this form.

Just that one sentence. Everything else—backup, secrets isolation, syntax checks, noise identification, profiling, scenario-specific optimization—were all execution steps it broke down on its own.