8/11/2025

Here’s the thing about being a long-time Emacs user: you get used to a certain way of working. Everything is a buffer, the keyboard is your home, & you’ve spent years, maybe even decades, honing a workflow that’s as powerful as it is personal. So when the AI coding revolution exploded, the question for many of us wasn’t if we should use these tools, but how we could integrate them without wrecking the beautiful, weird, & hyper-efficient environment we’ve built.
Pasting code into a web browser feels clunky. It yanks you out of your flow. You lose the context of your project, your LSP server, your custom keybindings. It’s just… not the Emacs way.
Turns out, there’s a MUCH better way. By combining the power of Anthropic's Claude with the flexibility of Emacs & the raw capability of Vterm (a fully-fledged terminal emulator inside Emacs), you can build an AI coding assistant that feels truly native. It’s not just a chatbot in a window; it’s an integrated part of your development environment that understands your projects, leverages your existing tools, & works with you, not against you.
This guide is for you if you're an Emacs user curious about bringing AI into your workflow in a way that feels right. We're going to walk through, step-by-step, how to get Claude running inside Emacs using Vterm. We'll cover the setup, the daily workflow, & some of the pretty cool advanced things you can do.

Why Bother? The Power of In-Editor AI

Before we dive into the nuts & bolts, let’s talk about why this setup is so compelling. What’s the actual, practical advantage over just having a Claude tab open in your browser?
The core idea is context.
When you’re working on a project, the context is everything. It’s not just the file you have open; it’s the entire directory structure, the other files that import or are imported by your current buffer, the linter errors popping up, the Git branch you’re on. A web UI knows none of this. It only sees the snippet of code you paste into it.
An integrated Emacs setup, however, is different. The tools we’ll use are project-aware. This means when you ask Claude a question, it can see the whole picture. You can say "Refactor this function, but make sure to update its usage in
1 src/utils/helpers.js
" & it can actually do that. It’s a HUGE difference.
Here are a few other reasons this is a game-changer:
  • Staying in the Flow: No more
    1 Alt-Tab
    bing to a browser. You stay in Emacs. The AI is just another buffer, accessible with the same keyboard-driven commands you use for everything else. This minimizes context switching & keeps you focused.
  • Leveraging Emacs Tools: The more advanced integrations allow Claude to use the tools you already have set up in Emacs. Got LSP-mode or Eglot configured? Claude can tap into that for code intelligence. Use Flycheck for on-the-fly error highlighting? You can literally point at an error & ask Claude to fix it.
  • Seamless Text & Region Sending: The workflow is incredibly smooth. Select a region of code, hit a keybinding, & it's sent to the Claude prompt. No copy-pasting required. It feels like a natural extension of your editing commands.
  • Conversation & History: Your interaction with Claude becomes a persistent conversation in a dedicated buffer. You can scroll back, see the evolution of a solution, & even resume previous conversations later.
Honestly, it transforms the AI from a simple Q&A bot into a true pair programmer that lives inside your editor.

The Key Ingredients: Claude-Code.el & Vterm

The magic behind this setup is primarily an Emacs package called
1 claude-code.el
by Steve Molitor. There's also a more advanced fork called
1 claude-code-ide
that introduces something called the Model Context Protocol (MCP) for even deeper integration, but for this guide, we'll stick to the foundational
1 claude-code.el
as it's a fantastic starting point.
Here’s what it does: It acts as a beautiful, seamless frontend for the Claude Code CLI tool. You install the CLI tool from Anthropic, provide your API key, & then this Emacs package manages starting, stopping, & interacting with the CLI from within Emacs.
And where does the CLI run? In a terminal emulator, of course! This is where Vterm comes in.
Vterm is a fully-featured terminal emulator that runs as an Emacs buffer. Unlike simpler shell buffers, it’s not just faking a terminal; it is one, built on
1 libvterm
. This means it can handle complex terminal applications with colors, proper cursor positioning, & interactive prompts—exactly what the Claude Code CLI needs. While the package also supports other backends like
1 eat
, we're focusing on Vterm. A Hacker News comment even points out that the package essentially wraps the CLI in Vterm & adds a bunch of conveniences on top, which is a perfect summary.
So the stack looks like this:
1 Emacs -> claude-code.el package -> Vterm buffer -> Claude Code CLI -> Anthropic API
It all works together to create a smooth, integrated experience.

Step 1: Prerequisites - Getting Your Ducks in a Row

Before we start customizing our
1 init.el
, there are a few things you need to have in place.

Emacs 30+ & Vterm

First, this setup works best with a modern Emacs, ideally version 30 or higher. The
1 claude-code.el
package depends on
1 transient
(the package that gives you those nice pop-up command menus), which is bundled with newer Emacs versions.
You'll also need to have Vterm installed & working. If you don't already have it, you can install it from MELPA. Make sure you have the necessary dependencies for Vterm itself, which usually involves compiling a small C module. The Vterm documentation is excellent, so check there if you run into issues. A typical
1 use-package
declaration for Vterm might look something like this:

Copyright © Arsturn 2025