Tích hợp Claude Code IDE cho Emacs

• Claude Code IDE for Emacs tích hợp Claude Code CLI một cách bản địa trong Emacs để cung cấp môi trường trợ lý lập trình AI mạnh mẽ
• Thông qua cầu nối hai chiều dựa trên Model Context Protocol(MCP), Claude có thể tận dụng các tính năng của Emacs như LSP, quản lý dự án, hàm Elisp, và nhiều chức năng khác
• Cung cấp các tính năng tối ưu hóa môi trường Emacs như phát hiện dự án tự động, phiên đa, tích hợp chẩn đoán (lỗi/cảnh báo), diff nâng cao, tab-bar và theo dõi lựa chọn/bộ đệm
• Dựa trên lệnh và khả năng mở rộng của Emacs, có thể đưa trực tiếp lệnh ra ngoài qua MCP server và tích hợp quy trình làm việc tùy chỉnh
• Xây dựng kết nối sâu giữa Claude và toàn bộ hệ sinh thái Emacs để tạo môi trường phát triển hỗ trợ AI trên nền tảng đám mây

---

Tổng quan

Claude Code IDE for Emacs là một dự án mã nguồn mở nhằm tối ưu hóa khả năng của Claude AI trong môi trường Emacs thông qua liên kết với Claude Code CLI. Khác với trình bao terminal đơn giản trước đây, gói này cung cấp cầu nối hai chiều dựa trên MCP (Model Context Protocol), được thiết kế để Claude có thể thực sự tận dụng các chức năng nội bộ của Emacs. Kết nối với hệ sinh thái mạnh mẽ của Emacs như LSP, quản lý dự án, hàm Elisp để tạo môi trường hỗ trợ phát triển AI thông minh và hiệu suất cao dành riêng cho người dùng Emacs.

Tính năng chính

• Phát hiện dự án tự động và quản lý phiên

  • Tận dụng project.el có sẵn trong Emacs, tự động nhận diện dự án và tách biệt phiên
  • Cung cấp phiên Claude Code và buffer riêng cho từng dự án

• Tích hợp terminal và hỗ trợ màu

  • Hỗ trợ terminal màu qua vterm hoặc eat
  • Có thể trò chuyện với Claude ngay trong Emacs

• Tích hợp IDE qua giao thức MCP

  • Tiếp xúc các lệnh Emacs đa dạng (duyệt mã, tra cứu ký hiệu, phân tích AST,...) qua MCP server
  • Claude có thể thực thi lệnh Emacs và hàm định nghĩa của người dùng

• Máy chủ MCP Tools mở rộng cao

  • Có thể thêm/định nghĩa MCP tool theo cá nhân hóa (ví dụ: tìm kiếm toàn dự án, refactoring toàn cục, v.v.)

• Chẩn đoán mã và diff

  • Cung cấp thông tin chẩn đoán lỗi/cảnh báo thông qua liên kết Flycheck, Flymake
  • Hỗ trợ truy cập thông tin chẩn đoán và chế độ xem diff nâng cao bằng ediff

• Quản lý chuyển đổi trạng thái/lệnh

  • Với tab-bar, theo dõi lựa chọn/buffer giúp Claude hiểu ngữ cảnh hiện tại của người dùng

Tích hợp Công cụ Emacs

Claude Code IDE trực tiếp phơi bày các lệnh và thông tin đa dạng của Emacs cho Claude thông qua hệ thống MCP tool

• Tích hợp LSP(xref)

  • Hỗ trợ điều hướng thông minh dựa trên LSP như go-to-definition, duyệt ký hiệu/tham chiếu toàn dự án

• Hỗ trợ Tree-sitter

  • Cung cấp phân tích cú pháp cây và hiểu cấu trúc mã dựa trên AST (Abstract Syntax Tree)

• Tích hợp Imenu, Project

  • Tự động cung cấp danh sách ký hiệu, thông tin file và cấu trúc dự án

• Hàm Elisp tùy chỉnh

  • Đưa trực tiếp lên MCP tool để tận dụng quy trình làm việc/đặc thù miền riêng

Với sự tích hợp này, Claude có thể tận dụng bối cảnh hệ sinh thái Emacs để cung cấp hỗ trợ AI chính xác đến cấp độ mã nguồn

Cách sử dụng

Lệnh cơ bản

• M-x claude-code-ide-menu: gọi menu transient hiển thị trực quan mọi lệnh
• Kích hoạt Claude Code trong dự án, gửi prompt, tiếp tục cuộc trò chuyện trước, và quản lý nhiều trạng thái/phiên
• Có thể quản lý cùng lúc nhiều dự án, vận hành phiên Claude riêng cho từng dự án

Quản lý cửa sổ và phiên

• Nếu một phiên mới đã đang chạy, chỉ thực hiện bật/tắt hoặc hiển thị cửa sổ
• Dù đóng cửa sổ bằng lệnh Emacs chuẩn (C-x 0), Claude vẫn không bị tắt

Cài đặt

• Hỗ trợ tùy chỉnh chi tiết về Claude Code CLI, backend terminal, backend chẩn đoán, vị trí/kích thước cửa sổ, tùy chọn gỡ lỗi
• Cung cấp các tùy chọn nâng cao như thêm flag, chỉ định system prompt, hàm đặt tên buffer
• Có thể kích hoạt MCP server và chỉ định tool/cổng sử dụng

Cấu hình Terminal Backend

• Mặc định là vterm, có thể chuyển sang eat khi cần
• eat là terminal thuần Elisp, hữu ích khi vterm gặp lỗi biên dịch
• Có keybinding riêng (M-RET: xuống dòng trong prompt, C-<escape>: thoát/hủy, v.v.)

Tùy chọn chẩn đoán/gỡ lỗi

• Có thể tự động phát hiện/kết nối hoặc chỉ định bắt buộc Flycheck, Flymake
• Có tùy chọn tạm thời tích hợp nhằm tránh lỗi tái diễn của Claude terminal reflow (#1422)
• Hỗ trợ nhật ký gỡ lỗi chi tiết ở cấp Emacs và CLI (xem WebSocket, thông điệp JSON-RPC, v.v.)

Advanced: nhiều Worktree, vận hành phiên

• Sử dụng git worktree, cho phép chạy nhiều phiên độc lập theo nhánh trong cùng một dự án
• Duy trì buffer và ngữ cảnh riêng cho từng nhóm tác vụ, hỗ trợ quy trình phát triển song song

Chi tiết Emacs MCP Tools

Ví dụ MCP Tools tích hợp

• xref-find-references: duyệt toàn bộ tham chiếu của một ký hiệu cụ thể trong dự án
• xref-find-apropos: tìm kiếm mã/biểu tượng toàn diện theo mẫu
• treesit-info: cung cấp dữ liệu phân tích AST dựa trên tree-sitter
• imenu-list-symbols: xuất toàn bộ danh sách hàm, biến trong file
• project-info: cung cấp metadata dự án và thông tin file hiện tại

Thêm công cụ tùy chỉnh

• Người dùng có thể thêm Emacs function của riêng mình theo định dạng MCP tool
• Ví dụ, bạn có thể định nghĩa công cụ tìm kiếm mã với ripgrep hoặc lệnh chuyên ngành riêng rồi gọi trực tiếp từ Claude

Giấy phép và dự án liên quan

• Cung cấp theo GNU GPL v3.0 hoặc cao hơn
• Giới thiệu các dự án liên quan như plugin tích hợp VS Code, Neovim (claudecode.nvim), v.v.

Tầm quan trọng và điểm nổi bật

Claude Code IDE for Emacs phân biệt bản thân khỏi các công cụ tích hợp LLM/AI khác bằng khả năng khai thác sâu ngữ cảnh làm việc nội tại và thông tin hệ sinh thái Emacs trong môi trường Dù ở giai đoạn tương đối đầu, nó vẫn có nhiều tính năng nội tại, khả năng tùy biến cao và hỗ trợ đa dự án, trở thành lựa chọn mạnh mẽ cho người dùng Emacs và nhà phát triển mã nguồn mở

[GN⁺]

Ý kiến từ Hacker News

• Giống như LSP và tree-sitter, các công cụ AI coding như Claude Code hay Aider là tín hiệu rất vui cho những editor như Emacs hoặc Vim vốn thường bị coi là thị trường ngách, vì không cần phải tự dựng lại các tính năng IDE cao cấp như trước; ta có thể dễ dàng tích hợp với các công cụ này rồi tập trung vào điểm khác biệt riêng của việc chỉnh sửa của mình, và thực ra tính năng tùy biến cùng khả năng liên kết linh hoạt này đã nâng đáng kể năng lực cạnh tranh của các editor đó.
  • Tò mò không biết có chuẩn nào giống như LSP để tích hợp dễ các công cụ coding theo kiểu agent vào editor hay không.
  • Cảm giác này luôn đúng như mình nghĩ: Emacs và Vim đã có các tính năng IDE cao cấp từ lâu; nhờ LSP và tree-sitter, việc chuẩn hóa theo hướng bao trùm editor-ngôn ngữ giờ dễ hơn nhiều.
  • Mình không đồng ý nói Emacs là một editor ngách; nó đã là một trong những editor đại diện rồi.
• Mình luôn nghĩ Emacs là editor tốt nhất cho AI agent, vì agent có thể dễ dàng đọc toàn bộ trạng thái editor và thậm chí đổi cả hành vi bằng elisp. Các editor cho phép tùy biến kiểu Vim/Emacs như vậy có lẽ sẽ vẫn có lợi thế lớn trong tương lai.
  • Vim hay Emacs thực ra luôn có ưu điểm lớn theo cách này; ai cũng có tiêu chí đánh giá khác nhau, nhưng cá nhân mình thấy tính mở rộng đóng kín của VSCode hay IntelliJ là nhược điểm lớn. Đóng kín ở đây nghĩa là API plugin hạn chế, môi trường sandbox, cơ cấu phê duyệt của doanh nghiệp, nội bộ logic khó minh bạch,… Trước đây mình từng cố chuyển sang IDE khác để tìm tính năng mới, nhưng bây giờ chỉ cần học Emacs đã giúp mình tiếp cận mục tiêu tốt hơn. Cách giải quyết vấn đề khi dùng Emacs khiến mình thấy thoải mái hơn hẳn so với khi dùng IDE.
  • Điểm mạnh của Emacs nằm ở lõi interpreter Lisp; AI agent có thể soi trực tiếp toàn bộ trạng thái editor tại runtime bằng cùng cơ chế đánh giá như người dùng và can thiệp vào nó, trong khi phần lớn editor khác chỉ có API plugin cứng nhắc, cố định.
• Mình đang dùng khá hài lòng plugin claude-code.el, dù chỉ là wrapper terminal thuần nhưng vẫn có menu Transient rất mạnh. Chỉ cần chạy trong Emacs thôi thì đã giúp luồng làm việc hiệu quả hơn nhiều, tạo được quy trình cá nhân hóa dễ dàng hơn nhiều so với môi trường iTerm trước kia. Sẽ tiếp tục theo dõi sát sao các package mới ra trong thời gian tới, và cũng đang mong đợi eca-emacs. Với các tool mà mình cần tin vào năng suất, mình thường tiếp cận ban đầu rất thận trọng; thường là qua một giai đoạn “big bang” cần sửa rất nhiều cho các dự án lớn.
  • Mình thử một thời gian rồi cuối cùng vẫn quay lại dùng lại claude code trong terminal thôi; trong Emacs có chút giật và không thực sự có lý do để không mở thêm cửa sổ terminal riêng. Cũng tiếc là chưa tích hợp với package mcp.el. Khi thử claude code trong công việc, chất lượng code tôi cần chưa đạt mức mong muốn, và mcp.el cũng đáng để xem thử.
• Emacs hội nhập LSP, tree-sitter và các tool mới như Claude Code là điều đáng mừng, nhưng đồng thời việc thiết lập cảm giác đang khó hơn thật. Dù là user Emacs 20 năm, bây giờ cấu hình môi trường không còn dễ như trước. Có lẽ giai đoạn dễ nhất là trước khi Claude Code có tích hợp IDE (chỉ chạy lên là xong, gần như không phải bận tâm đến đồng bộ buffer tự động). Trên macOS mới, mình mới chỉ chạy được typescript-ls, còn gopls thì chưa tải về được; có một hai giờ là sửa được, nhưng việc dò ra điểm nghẽn rất phiền. Nên chia sẻ để thấy anh em Emacs user giờ đang làm sao. Gần đây mình đang coding vui với Zed; không dễ gì bỏ được 20 năm quen thuộc của Emacs. Khả năng chỉnh file config nhỏ lẻ tới hỗ trợ dự án quy mô lớn, cùng mức độ tùy biến cực cao của Emacs vẫn cực kỳ đáng quý. Liệu Neovim có đi hơn về hướng này không? Mình cũng băn khoăn liệu có nên học debug elisp kỹ hơn để hiểu lệnh mình chạy tác động môi trường ra sao; do đã quen keybinding Emacs (thậm chí cả Dvorak), không biết trải nghiệm Neovim sẽ khác nhiều đến đâu.
  • Debug elisp thì mình khuyên nên làm, dù đã dùng Emacs nhiều chục năm vẫn có rất nhiều người chưa biết built-in profiler, edebug, apropos, macro expansion, advising system, indirect buffer. Nếu ví Emacs như một chiếc xe, nó là kiểu máy móc có thể lắp thêm linh kiện và đổi sang “máy ngầm” ngay khi đang chạy, nên đòi hỏi tư duy giải quyết vấn đề cơ bản và chấp nhận tình huống bất ngờ. Khi gặp lỗi, mình có thể tìm ngay điểm đứt rồi viết elisp đúng cho hook/advise trực tiếp trong gptel buffer để thử, cảm giác giải phóng đó phải tự trải nghiệm mới thấy. Dạo này mình cũng không còn bận tâm quá về config “sạch”; chỉ cần module hóa tốt rồi thêm elisp khi cần. Khi lỗi do cập nhật package bên ngoài hoặc nguyên nhân ngoài khởi tạo, thường chỉ mất vài phút để tìm nguyên nhân rồi có cách thay thế, và tần suất cũng ít.
  • Để quản lý vấn đề môi trường, mình đang chạy Emacs trong Docker; xem emacs-native-dockerfiles
  • Khi tích hợp hệ sinh thái ngôn ngữ mới vào Emacs, tự chọn package và tool bên ngoài (như LSP server, v.v.) đã rất mất công; nhiều dự án chỉ ở mức “dabbling” nên luôn phải cân nhắc. Về thực tế, khi tải/cài tool bên ngoài mình dùng Nix (devenv.sh), direnv... để Emacs không tự tải mà chỉ gắn path, và lưu file cấu hình liên quan bằng devenv để đồng đội cùng dùng một môi trường.
  • Dù là user Emacs 8 năm, nhưng hai tháng qua mình đã chuyển hẳn sang nvim và đã không mở Emacs cả tháng; đang cài lazy.vim rồi luân phiên dùng AI plugin. Gần đây hệ sinh thái và cộng đồng nvim lại còn sôi nổi hơn, mà ThePrimeagen cũng đáng để xem.
  • Kinh nghiệm với Neovim cũng tiến rất xa, có thể set up linh hoạt từ barebone đến đủ tính năng IDE. Đã có nhiều bản phân phối pre-configured, có thể xem LazyVim. Các AI plugin cũng tham khảo awesome-neovim #ai
• Cần tích hợp chặt chẽ hơn với org mode, hoặc AI cho note-taking tổng quát hơn; mình thực sự thấy thiếu. Dùng github/copilot mà sau 30 ngày thì xóa nội dung chat khiến việc xây knowledge base bằng AI rất ảnh hưởng, nên nhu cầu quản lý nghiên cứu và ghi chép locally giống Google notebookllm đã trở nên rất rõ.
  • Khuyên thử gptel-mode, hội thoại được lưu trong org buffer, session có thể lưu và restore dễ, và tích hợp mcp.el tốt.
  • ob-aider cũng đáng để xem, liên kết ob-aider
• Tính năng thêm công cụ vào mcp server cực kỳ hài lòng, đúng kiểu Emacs như mong đợi. Mình đã dùng vài năm nhưng gần đây viết elisp trực tiếp nhiều hơn, Claude cũng hỗ trợ viết elisp khá tốt nên dùng nhiều hơn nữa (thi thoảng phải tự chỉnh lại căn thụt ngoặc, nhưng nhìn chung ổn), và mình sẽ thử efrit của Steve Yegge. Khả năng agent chạy và thực thi một biểu thức elisp bất kỳ đẩy giới hạn của Emacs lên một cấp, efrit
  • Mình là fan và follower lâu năm của Yegge; vẫn nghĩ đây mới là giai đoạn “honeymoon” của vibe code, nhưng năng lực Emacs của anh ấy thì mạnh hơn ai hết. Từ 1-2 năm trước mình đã nhận ra LLM lớn bắt đầu rất mạnh với elisp, và đó là cái chốt cho dự án hypermodern. Mình thấy efrit rất tiềm năng (mặc dù chưa setup được hoàn chỉnh).
• Cùng lúc có hơn 5 package tích hợp Emacs/Claude Code và hai ba package đang cạnh tranh nóng trên Reddit, điều này thú vị, nhưng các plugin thực sự rất mạnh hình như lại tồn tại lặng lẽ và ít ai nhắc đến. yuya373/claude-code-emacs dường như đã gần như cài sẵn gần như toàn bộ chức năng của các bản cạnh tranh.
  • Không rõ mức độ phổ biến, nhưng có vẻ đây là package dễ cài nhất; xem melpa claude-code
  • Plugin đó hình như chưa có tích hợp /ide của Claude-code-ide
• eca cũng nên thử, team đó đang tập trung làm công cụ AI pair programming tốt nhất trên Emacs.
• Mình có cảm giác gần đây trong cộng đồng Emacs đang có xu hướng chê bai luôn cả việc bàn về tích hợp AI này, nhưng thật ra phản ứng đó theo mình gây hại nhiều hơn lợi. Ngay cả khi AI phát triển theo hướng khác thế hệ hiện tại, tôi nghĩ gốc Emacs nằm tại MIT AI Lab; do đó việc dè dặt với các tool bắt nguồn từ AI working group như vậy là bất thường.
  • Sức hấp dẫn của Emacs là quyền kiểm soát trong tay user; có thể đổi bất cứ thứ gì ở lớp Elisp nên các package như này cứ thế xuất hiện. Ngược lại, VS Code theo thiết kế dễ đẩy tới phân mảnh: Microsoft dùng API riêng cho công cụ độc quyền của họ, còn với bên ngoài chỉ cho API mở rộng giới hạn hơn rất nhiều, nên mới có rất nhiều vscode fork. Emacs có một developer Elisp cực có đam mê và kỹ năng là có thể sửa mọi thứ, và module AI/LLM mới có thể mọc bất kỳ lúc nào. Mình thấy phê phán trong cộng đồng Emacs cũng khá phóng đại; thực tế các plugin AI/LLM vẫn liên tục ra và nhận phản hồi tốt, ví dụ như gptel
  • Nguyên nhân bầu không khí này do Richard Stallman; ông cho rằng khi dự án phần mềm tự do chưa sẵn sàng thì phải cảnh giác với giải pháp “non-free”. Cách tiếp cận ấy đã làm chậm việc thông qua nhiều quyết định như GCC extension, LLVM debugger, tree-sitter, git/bzr, CI build farm, khiến tốc độ áp dụng thay thế cho các dự án cốt lõi như Emacs bị kéo dài; cuối cùng thì luôn chậm trễ rồi mới chấp nhận, đôi khi có vẻ là để giữ vị thế FSF.
  • Cộng đồng Emacs cực kỳ đa dạng, phản ứng tiêu cực có thể có ở đâu cũng vậy, mình nghĩ không cần quá để tâm. Bất kỳ tính năng nào cũng có thể bổ sung qua module của bên thứ ba, và maintainer cốt lõi không có cách nào chặn được.
  • Việc MIT AI Lab liên thông với cơn sốt AI hiện đại là điều mình vừa mới biết, khá thú vị.
• Mình rất mong chờ các tool này, mình thích cách kết hợp Emacs với AI vào luồng coding. Nhưng hơn hết, điều mình cần là chạy được tất cả trực tiếp local trên phần cứng dưới 2000 đô; liệu hiện tại hay gần tương lai có khả thi không? Và có ai đang dùng agent coding chạy local model chưa?
  • Có tiến bộ cực lớn về suy luận tiết kiệm bộ nhớ và model coding tối ưu cho mã nguồn mở; gần đây nhóm Qwen3-Coder đang nhận nhiều chú ý (Qwen3-Coder), còn local runtime thì có Ollama, LM Studio. Tùy model size/quantization, với ngân sách $2000 có thể chạy được rất nhiều model; Mac M-series cũng cho hiệu năng/chi phí tốt. Thông tin về local LLM nhiều ở subreddit LocalLlamas. Dù khác xa quy mô lab AI lớn, nếu ưu tiên cấu hình hoàn toàn local thì đây vẫn là dự án khá thú vị và đáng thử.
  • gptel hỗ trợ nhiều model, kể cả local
  • MacMini hay frame.work desktop, hoặc Nvidia DGX Spark cũng là một lựa chọn (giá thấp nhất 3k)