Warp, Fig, and Starship Conflict with Zsh Plugins

Warp Fig Starship Zsh compatibility issues show up the moment a developer tries to combine all three tools in one terminal setup. Warp ships with its own prompt engine. Starship expects to control the prompt itself. Fig, meanwhile, injects initialization code at specific points in the zshrc file, and if that placement gets disturbed, the whole shell can misbehave on startup.

None of these tools are broken on their own. The friction comes from three separate projects making assumptions about who owns the terminal's rendering pipeline. Warp assumes it does, by default. Starship assumes it does, as a cross-shell prompt replacement. Fig assumes its scripts run first and last, untouched.

This piece walks through why the conflict happens, the exact zshrc configuration that resolves it, and the failure modes you'll hit if you skip a step. It's written for anyone building a modern developer terminal setup and running into rendering glitches, duplicate prompts, or missing icons.

#The Core Conflict: Why These Tools Fight

Warp is a terminal built around its own interface layer, not a plain wrapper around your shell. It comes with a native prompt, and that prompt is enabled by default. According to a GitHub discussion on the starship/starship repository, Warp requires custom prompt support to be turned on manually before Starship's prompt will even display.

If you skip that setting, Starship's config will load fine, but you'll never see it. Warp's own prompt will keep rendering on top, silently ignoring the theme and modules you just spent an hour configuring.

Fig adds a second layer of complexity. Fig's plugin framework injects shell initialization code at the very top and very bottom of your zshrc file, according to the same GitHub discussion. It expects those two blocks to stay exactly where its installer put them.

Starship also needs an init line, and that line typically goes at the bottom of zshrc too. If you paste it in the wrong spot, or above Fig's closing block instead of below it, you get race conditions. The prompt might load twice, load with missing colors, or not load until you open a second terminal tab.

Put simply: Warp wants to own the prompt, Fig wants to own the file structure, and Starship wants to own both the rendering and the last word in the config. None of them are wrong. They just weren't built with each other in mind.

#Compatibility Matrix: Which Combinations Actually Work

Not every shell and terminal pairing behaves the same way. Bash and zsh handle Starship's hooks differently, and Warp's rendering engine treats them differently too.

The starred row is the one that generates the most support tickets: bash as the default shell tends to break Starship's prompt rendering inside Warp.

According to Warp's official documentation, Starship may fail to render correctly in Warp when bash is set as the default shell. The recommended fix is to upgrade bash and confirm the shell path is correctly pointed to in Warp's settings, or better yet, switch to zsh as the default shell entirely.

Zsh is the safer choice across the board. It's what Starship's own examples assume, it's what Fig's installer targets by default, and it's the shell Warp's documentation leans on for its own configuration examples.

#The Setup That Works: Exact Configuration Order

Getting all three tools to cooperate is less about clever tricks and more about sequencing. Install in this order, and edit zshrc in this order, and most conflicts disappear.

• Install zsh and set it as your default shell.
• Install Fig first, and let its installer modify zshrc automatically.
• Install Starship, but do not let its installer auto-edit zshrc yet.
• Open zshrc and confirm Fig's two blocks are still at the very top and very bottom.
• Add the Starship init line directly above Fig's closing block, never below it.
• Open Warp settings and enable custom prompt support.
• Restart the terminal completely, not just the current tab.

A minimal working zshrc, with Fig's markers represented as placeholders, looks like this:

# Fig pre block start
# (Fig-managed initialization, do not edit)
# Fig pre block end

# your normal aliases and exports go here
export EDITOR="nvim"

eval "$(starship init zsh)"

# Fig post block start
# (Fig-managed initialization, do not edit)
# Fig post block end

The key detail is that Starship's eval line sits between Fig's two managed blocks, not after them. If it ends up below Fig's closing block, Starship sometimes initializes after Fig has already claimed control of prompt-related environment variables, and the prompt either flickers or fails to load on the first shell open.

Common advice across community threads backs this up: keep Fig's scripts exactly where the installer put them, and slot Starship in between rather than appending it at the very bottom of the file.

#Font and Symbol Rendering: The Hidden Blocker

Even a perfectly ordered zshrc won't save you if the font is wrong. Starship uses icon glyphs for git status, language versions, and directory markers, and standard system fonts don't include them.

According to a setup guide from DevOps Crux, installing a Nerd Font variant, such as Hack Nerd Font Mono or Meslo Nerd Font, is required for Starship's symbols to render correctly inside Warp. Skip this step, and you'll see boxes, question marks, or blank gaps where icons should be.

To fix it:

• Download and install a Nerd Font (Hack Nerd Font Mono is a safe default).
• Open Warp settings and navigate to the appearance or font section.
• Set the font to the Nerd Font variant you just installed.
• Restart Warp fully.

This step gets skipped constantly because the terminal looks "done" without it. The prompt shows up, colors work, and everything seems fine until you notice the git branch icon is missing or replaced with a placeholder glyph.

#Known Failure Modes: What Breaks and Why

Even with a correct zshrc and the right font installed, a few specific problems keep showing up across support threads and documentation. Recognizing them saves hours of guessing.

Anyone doing CLI setup troubleshooting on this stack should check these five things before assuming a config file is corrupted or a tool is fundamentally broken.

#Performance and Trade-offs

Running Warp, Fig, and Starship together does add a small amount of shell startup overhead compared to using none of them. Each tool runs its own initialization script, and Fig in particular runs code at both the start and end of the file, according to the earlier-cited GitHub discussion.

For most users this delay is not noticeable on modern hardware. It becomes more relevant on older machines, or in setups with many additional zsh plugins layered on top, where every extra eval or sourced script adds a few more milliseconds to the shell's cold start.

The bigger trade-off isn't speed, it's fragility. A three-tool stack means three separate update cycles, and any one of them changing its init behavior can break the other two. Startup config that worked last month can silently stop working after a Fig or Starship update changes where or how it expects to hook into zshrc.

That's the real cost of Zsh plugin incompatibility risk in a setup like this: not slowness, but maintenance burden. Every update to any one tool is a reason to re-check the other two.

#Alternatives to Consider

Not every developer needs this exact combination. If the goal is just a clean, informative prompt, Starship alone inside Warp, without Fig, avoids almost every conflict described above. Warp's custom prompt setting still needs to be enabled, but there's no script-ordering puzzle to solve.

If the goal is Fig's autocomplete and workflow features without a custom prompt, skipping Starship entirely and using Warp's native prompt sidesteps the rendering fight altogether. Warp's default prompt is capable enough for most day-to-day work, and it's the one path guaranteed not to fight with Fig's zshrc injections.

For developers who want prompt customization but not the third-party layering, some choose iTerm2 or Kitty with Starship instead of Warp, since neither of those terminals ships a competing native prompt that needs to be manually disabled.

#FAQ

A: Warp ships with its own built-in prompt system enabled out of the box. According to Warp's documentation, custom prompt support has to be turned on manually in settings before tools like Starship can take over rendering.

A: Order matters for the zshrc file, not necessarily the install sequence. Fig's installer expects to manage the top and bottom blocks of zshrc, so Starship's init line should be added between those blocks rather than appended after them.

A: Check that Warp's font setting actually points to the Nerd Font variant, not just that the font is installed on the system. Many rendering failures come from the font being present but not selected inside Warp's appearance settings.

A: On most modern machines, the added delay is small. It becomes more noticeable with many additional zsh plugins stacked on top, since each one adds its own initialization step.

A: Technically yes, but Warp's own documentation notes rendering problems with Starship under bash, and the community-recommended fix is switching to zsh as the default shell.

#Takeaways

Getting Warp, Fig, and Starship to work together comes down to four things: enable custom prompt support in Warp, keep Fig's zshrc blocks untouched, place Starship's init line between them, and install a Nerd Font before worrying about anything else.

• Switch to zsh as the default shell before troubleshooting anything else.
• Enable custom prompt support in Warp's settings so Starship can actually display.
• Never move or edit Fig's auto-generated zshrc blocks.
• Add Starship's init line between Fig's pre and post blocks, not after both.
• Install and select a Nerd Font inside Warp before checking icon rendering.
• Restart the terminal fully after any zshrc change, not just the active tab.

Get those six steps right, and this particular corner of modern shell customization stops being a fight and starts being a setup you configure once and forget about.