Git

Git Rebase Interactive Editor Not Opening or Failing

When git rebase -i doesn't open an editor at all, hangs, or fails immediately, the cause is almost always that Git's configured editor either isn't set correctly, points to an editor that doesn't behave well as a blocking terminal command, or isn't available in the current environment at all.

The Problem

Running an interactive rebase either does nothing visible, immediately completes without giving you a chance to edit anything, or throws an error:

git rebase -i HEAD~3
error: cannot run editor: No such file or directory
error: unable to start editor 'nano'

Or the command appears to hang indefinitely with no visible prompt at all.

Why It Happens

Interactive rebase depends on Git launching a text editor and waiting for it to close before continuing — several common misconfigurations break this:

  • No editor is configured at all, and Git's fallback default isn't available in the current environment (common in minimal server environments, containers, or CI runners without a text editor installed)
  • The configured editor is a GUI application (like VS Code) launched incorrectly — without the correct flag telling it to wait until the file is closed before returning control, Git thinks the edit is immediately done and proceeds before you've actually made any changes
  • The configured editor genuinely isn't installed or isn't in the system's PATH, even though it might be referenced correctly in Git's configuration
  • Running Git inside certain terminal environments (some IDE-embedded terminals, certain CI contexts) that don't properly support launching an interactive terminal-based editor like vim or nano

The Fix

Check your current editor configuration:

git config --get core.editor
echo $EDITOR
echo $VISUAL

Git checks these in a specific order — core.editor, then $VISUAL, then $EDITOR, falling back to a platform default (often vi) if none are set. Confirm what's actually being used, and whether it's genuinely available.

For a straightforward terminal-based editor that reliably works in almost any environment, set nano explicitly if it's installed:

git config --global core.editor "nano"

If you prefer VS Code as your editor, the critical detail is using the --wait flag, without which VS Code returns control to Git immediately rather than waiting for you to actually finish editing and close the file:

git config --global core.editor "code --wait"

Without --wait, Git proceeds with the interactive rebase's default, unedited plan the instant the file opens, which produces exactly the symptom of "the rebase seemed to just complete without giving me a chance to change anything."

For Sublime Text, a similar wait flag is required:

git config --global core.editor "subl -n -w"

If you're in an environment where no GUI editor is practical (a remote server, a container, certain CI contexts) but a terminal editor like vim or nano genuinely isn't installed, install one directly:

# Debian/Ubuntu
sudo apt-get install nano

# Alpine
apk add nano

If you're running Git inside an environment that fundamentally can't support an interactive terminal editor (some restricted CI runners, for example), consider whether the interactive rebase step genuinely needs to happen in that environment at all — interactive rebases are typically a local development operation, not something that should run as part of an automated pipeline, since they require human decision-making about which commits to squash, reorder, or edit.

Still Not Working?

If the editor configuration looks correct but the rebase still fails or behaves unexpectedly, test the editor configuration in isolation, outside of the rebase context, to confirm it works as a standalone command first:

git config --get core.editor
$(git config --get core.editor) test_file.txt

If this standalone test also fails or behaves unexpectedly, the problem is confirmed to be in the editor configuration or installation itself, not specific to rebase — troubleshooting the editor launch command directly, separate from Git entirely, is the more productive next step rather than continuing to debug through repeated rebase attempts.

You might also like