Best Emacs Claude Code Integration: What Actually Works

If you're searching for the best Emacs Claude Code integration, you're probably choosing between three real options: running the Claude Code CLI inside an Emacs terminal buffer, using an Emacs-native LLM package like gptel configured against Claude, or wiring Claude into Emacs through MCP or a direct API call. There isn't one "official" plugin that does everything — Emacs integration with Claude Code is mostly about picking the right combination of terminal emulation, package configuration, and API access for how you actually work.

This guide walks through each approach, what it's good for, and where it breaks down, so you can pick the setup that fits your workflow instead of copy-pasting a config that doesn't match how you use Emacs.

Option 1: Claude Code CLI in a terminal buffer

The simplest and most reliable integration is running the actual Claude Code CLI inside Emacs using vterm or eat (Emulate A Terminal). This isn't a "plugin" in the traditional sense — it's just Emacs acting as your terminal multiplexer, which is exactly what most Claude Code users want: full CLI behavior, streaming output, and tool-use approval prompts rendered correctly.

vterm is the more mature choice because it uses a native module for real terminal emulation, which matters for Claude Code's interactive prompts and ANSI rendering:

(use-package vterm
  :ensure t
  :commands vterm)

(defun my/claude-code ()
  (interactive)
  (vterm-other-window)
  (vterm-send-string "claude")
  (vterm-send-return))

Bind that to a key and you get a Claude Code session in a split window, next to your actual buffers. It's not deeply integrated — you can't send a region directly into a running session out of the box — but it's stable and it doesn't fight Emacs for control of the terminal.

eat is a newer, pure-Elisp alternative if you want to avoid compiling a native module:

(use-package eat
  :ensure t
  :hook (eshell-load . eat-eshell-mode))

Either way, this approach treats Claude Code as an external process, which means anything the CLI supports (file edits, tool calls, project context) works exactly as it does in a regular terminal — no half-implemented feature set.

Option 2: gptel and Emacs-native LLM packages

If you want a more "Emacs-first" experience — asking questions from any buffer, streaming responses inline, sending regions for review — packages like gptel are a better fit than shelling out to the CLI. gptel supports Anthropic's API directly and works well for code review, explanations, and quick refactors without leaving your buffer.

(use-package gptel
  :ensure t
  :config
  (setq gptel-model 'claude-opus-4
        gptel-backend
        (gptel-make-anthropic "Claude"
          :stream t
          :key "sk-ant-...")))

This gives you inline chat, region-based prompts, and streaming — genuinely useful for staying in flow. The tradeoff is that gptel talks to Claude's chat API, not the full Claude Code agent loop, so you lose things like autonomous multi-file edits, tool execution, and project-wide context that the actual CLI provides. Think of it as a strong complement to Claude Code, not a replacement.

Option 3: MCP servers from Emacs

If your workflow depends on Model Context Protocol servers — filesystem access, git tools, database queries — some Emacs setups now proxy MCP calls through packages that speak to a running MCP-compatible client. This is still early and fragmented compared to VS Code or JetBrains MCP support, and most Emacs users get more mileage running Claude Code's CLI (which handles MCP natively) in a terminal buffer rather than trying to reimplement MCP orchestration in Elisp.

If MCP is central to your workflow, Option 1 — running the real CLI in vterm — is usually less work and more reliable than any Emacs-native MCP client today.

Option 4: Calling the API directly for custom Emacs tooling

Some developers skip both the CLI and off-the-shelf packages and write their own small Elisp functions that call an API endpoint directly — useful if you want a custom command like "explain this function" bound to a specific key, with your own prompt template and response formatting.

The friction here is usually credential and access management: raw Anthropic API keys don't give you per-project usage visibility, and if you're building this for a team, everyone ends up with their own key and their own bill. This is where SubToAPI is a practical option — it turns your existing Claude access into a standard HTTPS API with application-scoped keys (sub_live_...), so your Elisp function calls one clean endpoint instead of juggling raw provider credentials, and you get usage metadata and team seats if more than one person on your team is building Emacs tooling against it.

A minimal example calling a Claude-backed endpoint from Elisp using url.el:

(defun my/ask-claude (prompt)
  (let ((url-request-method "POST")
        (url-request-extra-headers
         '(("Content-Type" . "application/json")
           ("Authorization" . "Bearer sub_live_xxx")))
        (url-request-data
         (json-encode `(("model" . "claude-sonnet-4")
                        ("messages" . [((role . "user") (content . ,prompt))])))))
    (url-retrieve "https://api.subtoapi.app/v1/messages"
                  (lambda (status) (switch-to-buffer (current-buffer))))))

Check the quickstart docs and the messages endpoint reference if you go this route — it's the same request shape regardless of what editor is calling it, which makes it easy to reuse the same backend for a CLI tool, an Emacs function, and a CI script.

Which one should you actually use?

• Want the full Claude Code agent (multi-file edits, tool use, project context)? Run the CLI in vterm. It's not fancy, but it's correct.
• Want quick inline chat and code explanations without leaving a buffer? Use gptel configured for Anthropic.
• Want a custom Elisp workflow or a shared team backend? Build against an API endpoint — SubToAPI if you want key management, streaming, and usage tracking without standing up your own proxy.

For most people, the honest answer is: run the real CLI in a terminal buffer for actual coding work, and layer gptel on top for quick lookups. Trying to reimplement Claude Code's full feature set as native Elisp is more effort than it's worth right now.

Questions

Is there an official Claude Code Emacs package? No. The most reliable setup is running the Claude Code CLI inside vterm or eat, since it behaves as a real terminal process rather than a partial reimplementation.

Does gptel support Claude the same way as Claude Code? No — gptel talks to Claude's chat API for inline conversations and region prompts, but it doesn't run the agentic tool-use loop that Claude Code's CLI provides.

Can I build a custom Emacs command that calls Claude directly? Yes, using url.el or request.el against an API endpoint. Services like SubToAPI simplify this by giving you a single HTTPS endpoint and API key instead of managing raw provider credentials for a small tool.