# claude-code.el, an Emacs front end for the Claude Code CLI

> stevemolitor/claude-code.el keeps the Claude Code session inside Emacs, so you send the current buffer, a region or a flycheck error to Claude and answer with a keystroke, without switching to a terminal. It needs Emacs 30, three terminal backends to choose from, and a transient menu for the slash commands.

**stevemolitor/claude-code.el** — Claude Code Emacs integration

- Repository: https://github.com/stevemolitor/claude-code.el
- Stars: 746 · Forks: 78
- Language: Emacs Lisp
- License: Apache-2.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/stevemolitor-claude-code-el

## What the package does

claude-code.el is an Emacs interface for the Claude Code CLI, providing integration between Emacs and Claude for coding assistance, and the feature list is the best description of what that means in practice.

The central idea is staying in your buffer. You send code, regions or commands to Claude while keeping your focus, and answers come back with a keystroke. The list of answer keys is <return>, <escape> and 1, 2 and 3, and there is no buffer switch in between.

Several features are aimed at specific editor annoyances. Point at a flycheck or flymake error and ask Claude to fix it, which is the case where a terminal round trip is most expensive because you lose the location. M-x yank-media sends a clipboard image to Claude as an @path reference, which needs Emacs 29 or newer. Smart context optionally includes file paths and line numbers when you send a command, so the response can talk about a specific place in a specific file.

Then there is the session management. Multiple instances let you run separate Claude sessions for different projects or tasks, and you can resume previous sessions or fork to earlier points.

Two features shape the whole interaction. Read-only mode toggles the buffer into a state where you can select and copy text with normal Emacs commands and keybindings, which is what you want when Claude is producing a patch and you want to read it. Mode cycling switches quickly between the default, auto-accept edits and plan modes, and the configuration example in the README even binds a repeat map so that pressing M after invoking the cycle command moves through them.

The transient menu gives access to all the commands and slash commands from the keyboard, which matters because the slash command set is large and the alternatives are typing them.

The package is Apache-2.0 licensed, written in Emacs Lisp, on the main branch, with the last push on 2026-04-30.

## Prerequisites and the terminal backend choice

The requirements are specific and worth reading before you try anything.

Emacs 30.0 or higher is required, and the Claude Code CLI has to be installed and configured separately. Two packages are required: transient at 0.7.5 or newer, and inheritenv at 0.2.

Then there is the terminal backend, and this is the decision that shapes the installation. Three are supported: eat at 0.9.2 or newer, vterm, and ghostel, which is the libghostty binding. The package works with all three, and the README links each.

There is a wrinkle in the eat path that the README calls out. If you are not using a :vc install, the eat package requires NonGNU ELPA, so the archive has to be added:

```elisp
(add-to-list 'package-archives '("nongnu" . "https://elpa.nongnu.org/nongnu/"))
```

The reason eat needs a separate archive is that it is not on MELPA, and the README notes in passing that vterm and ghostel are on MELPA.

The backend is worth choosing deliberately rather than defaulting. eat runs a terminal emulator inside Emacs with full compositing, which means you get real terminal behaviour, colours and applications that assume a terminal, at the cost of some graphical complexity. vterm is the simpler and more established choice, with the usual limitation that it does not handle the most recent terminal escape sequences well. ghostel is the newest and links against libghostty, so it inherits libghostty's handling of modern terminal features.

The third requirement is inheritenv, and it is the one that is easy to overlook. It exists so that the process Claude runs inside the terminal inherits the environment of the Emacs session, which is what makes your project tools, your PATH and your credentials available to Claude. Without it, a session starts with a stripped environment and commands that work in your shell fail in the session.

The final optional piece is Monet, recommended for IDE integration, and the configuration shows it being wired through a process environment hook.

## Installing it and how the session is wired up

There are two installation routes in the README, and the difference is in how the package is fetched rather than in how it works.

The first uses the built-in use-package, which is described as available for Emacs 30 and later:

```elisp
;; add melpa to package archives (vterm and ghostel are on melpa):
(require 'package)
(add-to-list 'package-archives '("melpa" . "https://melpa.org/packages/") t)
(package-initialize)

;; install required inheritenv dependency:
(use-package inheritenv
  :vc (:url "https://github.com/purcell/inheritenv" :rev :newest))

;; install claude-code.el
(use-package claude-code :ensure t
  :vc (:url "https://github.com/stevemolitor/claude-code.el" :rev :newest)
  :config
  (claude-code-mode)
  :bind-keymap ("C-c c" . claude-code-command-map)
```

The second route is straight.el, and the difference is in the package specification. Straight installs from the upstream source rather than from a package archive, and the eat example has to exclude the test files and point at specific directories:

```elisp
(use-package eat
  :straight (:type git
                   :host codeberg
                   :repo "akib/emacs-eat"
                   :files ("*.el" ("term" "term/*.el") "*.texi"
                           "*.ti" ("terminfo/e" "terminfo/e/*")
                           ("terminfo/65" "terminfo/65/*")
                           ("integration" "integration/*")
                           (:exclude ".dir-locals.el" "*-tests.el"))))
```

The Monet integration is added inside the :config block, through the process environment hook:

```elisp
  :config
  ;; optional IDE integration with Monet
  (add-hook 'claude-code-process-environment-functions #'monet-start-server-function)
  (monet-mode 1)
```

That hook name is the key piece of the design. The package exposes a list of functions that contribute to the environment the Claude process runs with, and Monet adds its IDE server to it. So the same mechanism that makes your shell environment available to the session is also the extension point for an IDE integration, which is a neat solution to a problem that otherwise has no obvious place.

The keybinding is bound to a command map rather than to individual keys, so you rebind the whole set rather than discovering the defaults one at a time. The repeat map for cycling modes is bound separately.

## How it fits against the alternatives

The alternatives are all variations on running the CLI in a terminal, and the differences are about how much of the editor you keep.

The first alternative is a plain terminal multiplexer, tmux with the CLI running in one pane and Emacs in another. That gives you several Claude sessions and persistent state, and it costs you the shared buffer. You copy code out, paste it in, and read the answer in the other window. For a quick question about a file, that is entirely adequate.

The second is the terminal inside Emacs, which is what the eat, vterm and ghostel backends are. This is the layer the package sits on, and choosing this package over a multiplexer buys you the buffer integration.

The third alternative is an editor-native agent integration, of which there are now several for the major editors. For a team that is not on Emacs, that is the more sensible comparison, and the general shape of the field is similar: an agent process runs alongside the editor, the editor sends it context, and the responses come back in a panel.

What the Emacs-specific version gives you is the error fixing case. Pointing at a flycheck error and having Claude fix it in place, with the location preserved, is the feature that a terminal workflow cannot do at all. The read-only mode and the mode cycling are the other two that matter, because they deal with the review step: you get the proposed change, you read it with your normal editing commands, and you decide what to accept.

The honest cost is the dependency chain. Emacs 30, transient, inheritenv, one of three terminal backends, and optionally Monet. That is a lot of moving parts for what is ultimately a wrapper around a CLI that runs in a terminal, and each one is a thing that can be on a different version than the package expects.

The inheritance detail deserves emphasis once more, because it is the thing most likely to cost an afternoon. If inheritenv is not doing its job, the Claude process has a different PATH from your shell, and the symptom is that a command which works when you run it does not work when Claude runs it. The README lists inheritenv as required, and the Monet hook shows the same mechanism serving the environment for the whole package.

## Conclusion

Adopt claude-code.el if you live in Emacs and already use the Claude Code CLI in a terminal, and you want the session to share your buffer, your project context and your keybindings. Skip it if you are happy with the terminal workflow, because the package adds a dependency on Emacs 30 and a specific terminal backend. Verify first by installing it with use-package from source, starting a session with a small file, and checking that the environment is inherited so your project tools are on the path inside the session.

## FAQ

### What does claude-code.el add on top of the Claude Code CLI?

It keeps the session inside Emacs so you can send the buffer, a region or a flycheck error to Claude and answer with a keystroke, plus support for pasting images, multiple sessions, resuming and forking, a transient menu of slash commands, read-only mode and mode cycling.

### What does claude-code.el require?

Emacs 30.0 or higher, an installed and configured Claude Code CLI, the transient package at 0.7.5 or newer and inheritenv at 0.2. One of eat, vterm or ghostel is needed as a terminal backend, and Monet is optional for IDE integration.

### Which terminal backends does claude-code.el support?

eat, vterm and ghostel, the last being the libghostty binding. The README notes that vterm and ghostel are on MELPA while eat needs the NonGNU ELPA archive added to package-archives if you are not using a :vc install.

### How do I install claude-code.el with use-package?

Add MELPA to package-archives, initialise the package system, install inheritenv from its git repository with a :vc spec, then install claude-code with a :vc spec pointing at the repository, binding C-c c to claude-code-command-map in the keymap argument and calling claude-code-mode in the config.

### How does the Monet IDE integration work in claude-code.el?

Through the claude-code-process-environment-functions hook, which the package exposes so that contributions to the environment of the Claude process can be added. The Monet example adds monet-start-server-function to that hook and then enables monet-mode.

## Sources

- [Issues](https://github.com/stevemolitor/claude-code.el/issues)
- [License: Apache-2.0](https://github.com/stevemolitor/claude-code.el/blob/main/LICENSE)
- [README](https://github.com/stevemolitor/claude-code.el/blob/main/README.md)
- [stevemolitor/claude-code.el on GitHub](https://github.com/stevemolitor/claude-code.el)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/stevemolitor-claude-code-el