[FEATURE] Add support for Microsoft Word (.docx) editing with track changes

Relevant to #2213, please consider higher priority for this.

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

This would be very useful indeed

Please support!

Would be useful

Please support

the ability to have 'tracked changes' (redlines) is crucial for almost every enterprise workflow that involves important documents

Please support, this would be excellent!

A quick update, there is a Skill from Anthropics that do just that
https://github.com/anthropics/skills/tree/main/skills/docx

A quick update, there is a Skill from Anthropics that do just that https://github.com/anthropics/skills/tree/main/skills/docx

I'm new to this level of depth for claude. How would you enable this skill for Claude Code specifically? All documentation i can find is for the claude.ai website.

Best thing to do is to ask Claude Code to add the skill and how to use it. Give him the URL and let it works.

You could give a try to docx-editor: "Python library for Word document track changes and comments".
https://github.com/pablospe/docx-editor

I created this little library that helps Claude to handle the complexity. If you want to install it the skill, follow the instructions, it is based on the original from Anthropic but using this library that make things faster and more reliable:
https://github.com/pablospe/docx-editor?tab=readme-ov-file#claude-code-skill

> A quick update, there is a Skill from Anthropics that do just that https://github.com/anthropics/skills/tree/main/skills/docx I'm new to this level of depth for claude. How would you enable this skill for Claude Code specifically? All documentation i can find is for the claude.ai website.

I checked the skill and it doesn’t work as expected or as the request here proposed. Still trying to find how to make an equivalent o Claude Code for Word.

Have you tried docx-editor? Could you tell me where it is failing? So maybe I could fix it.

Have you tried docx-editor? Could you tell me where it is failing? So maybe I could fix it.

Yes, I did some testing, and it works well, but there are some cases where it could be improved. See a summary from Claude Code below. Dealing with documents with multiple revisions, like deletions and insertions in the same sentence is painful.

Core limitation: Cannot find text that spans revision boundaries
Document structure:
"Exploratory Aim: " ← regular text
<w:ins>
"To examine whether..." ← inside insertion
</w:ins>

Search results:
"Exploratory Aim:" ✓ Found
"To examine whether" ✓ Found
"Exploratory Aim: To" ✗ NOT FOUND (spans boundary)
This happens because the library searches within XML elements individually rather than flattening all visible text into a continuous string before matching.
Practical impact:

Works perfectly on documents with no existing tracked changes
Works on documents with tracked changes if your edits target text fully inside or fully outside revision blocks
Fails silently when edits would span boundaries—no corruption, just can't find the text

How It Could Be Improved

Flatten-then-map approach — Build a virtual "visible text" string by concatenating all <w:t> content (excluding <w:delText>), then map character positions back to their source XML nodes. This is how Word itself handles search.
Boundary-aware splitting — When a match spans multiple XML contexts, split the operation into multiple tracked changes that respect boundaries:

User wants: replace "Aim: To" with "Goal: To"
Library does:

• Delete "Aim: " from regular text
• Insert "Goal: " before the <w:ins>
• Leave "To" inside the existing insertion untouched

Nested revision support — When deleting text inside an existing <w:ins>, properly nest <w:del> inside <w:ins> rather than treating them as separate operations. This preserves the full revision history.
Expose the complexity when needed — Provide a doc.get_visible_text_with_positions() method that returns both the flattened text and a position map, letting advanced users handle edge cases themselves.

The fundamental challenge is that OOXML represents revisions as structural changes to the XML tree, but users think about edits as operations on visible text. Bridging that gap completely requires significant complexity—which is likely why even Microsoft Word occasionally struggles with deeply nested revision histories.

Gemini output:
The Flaw: Text spanning revision boundaries is "invisible"
The docx-editor library cannot find, replace, or delete text if that text is split across different XML structures. This most commonly happens when a sentence has already been partially edited (e.g., half is original text, half is a tracked insertion).

Why this happens: The library treats a Word document as a collection of isolated text boxes (nodes) rather than a continuous stream of words.

How it works: When you search for a phrase, the library checks each individual text node (<w:t>) one by one to see if it contains your search string.

The failure point: It does not combine these nodes before searching. If your phrase "Exploratory Aim: To" is physically split in the XML file (e.g., "Exploratory Aim: " is in one node and "To" is in the next), the library looks at the first node, sees only a partial match, and moves on. It never "sees" the complete phrase.

How to Fix It
To support editing across boundaries, the library needs to move away from node-based searching to a "virtual text" approach.

1. Implement a "Virtual Text Map"

Instead of searching XML nodes directly, build a linear representation of the document's visible text that maps back to the DOM.

Mechanism: Create a helper that iterates through the w:body, concatenating text from valid w:t nodes while ignoring content inside w:del.

The Map: Maintain a mapping list where every character index in the string points to (xml_node, index_in_node).

Benefit: A search for "Aim: To" will successfully find the string in the linear text. The map then tells you exactly which nodes are involved (e.g., "Character 0 starts at Node A, index 12; Character 7 ends at Node B, index 2").

1. Rewrite replace_text to Handle Node Ranges

The current replace_text method assumes a match has a single w:r parent. This must be replaced with a multi-node operation:

Split Nodes: If the match starts in the middle of Node A, split Node A into two runs. Do the same for the end of the match in Node B.

Mark Deletions: Identify all "original" text nodes fully contained within the match range and wrap them in <w:del>.

Handle Insertions: If the match includes text that was already a tracked insertion (<w:ins>), the library must decide to either delete the <w:ins> tag entirely (effectively undoing the insertion) or wrap it in a deletion (which Word supports but is complex).

Insert New Text: Place the new <w:ins> element at the start of the range.

1. normalize "Runs" Before Searching (Partial Fix)

A simpler, less robust fix would be to implement a "Run Normalizer."

Mechanism: Before performing operations, scan the document for adjacent w:r elements that share the same properties (w:rPr) and are not separated by revision tags.

Merge: Merge these into a single w:r containing one w:t.

Limitation: This only fixes split text caused by formatting quirks. It does not fix the core issue of text split by revision tags (w:ins/w:del), which requires the "Virtual Text Map" approach above.

@gabrielpacosta can you help me with a "code" review of the openspec proposal, to see if I understood correctly the problems (let's move this discussion there):
https://github.com/pablospe/docx-editor/pull/2/changes#diff-d5bcf40e90f3a89fc967ab6470a804a783d541d69e59b889adf5a5fe4cb98ed9

Hey @pablospe @ceaston-trumid I'm building a fork of some docx-mcp server and I have improved it so that it has track change support. And versioning is built-in:

https://github.com/valdo404/docx-system/

To do this I have decided to rewrite everything using Microsoft official OpenXml SDK. That means the mcp server is able to work in a compliant manner using real fast native C# and Rust code. I'm planning a microsoft doc integration (using office.js) and a microsoft 365 / onedoc / sharepoint integration by the end of february .

It is using well known algorithms for diff calculation and change tracking, and JSON Patch semantics as well, and it is able to act in an agentic manner. I have seen that Anthropic has released official PPT and Excel plugins, but I plan to do it my way using office.js too.

Maybe you could help for debugging ?

Hey @valdo404 I have been actively working on the same thing, happy to help in any possible way as well. The goal is to get something as close as possible to the Excel plugin and Claude code feeling, but for Word

btw, I don't see how your MCP handles track changes which is one of the biggest challenges I have been facing.

I have begun working on it, although the track changes support is not in the README. There is preliminary support, and I plan to improve it soon. Will update the README soon. I need testers for this project.

Revision (Track Changes) commands:
  revision-list <doc_id> [--author name] [--type type] [--offset N] [--limit N]
  revision-accept <doc_id> <revision_id>     Accept a single revision by ID
  revision-reject <doc_id> <revision_id>     Reject a single revision by ID
  track-changes-enable <doc_id> <true|false> Enable/disable Track Changes

➜  docx-mcp git:(feat/sse-grpc-multi-tenant-20) ✗ docx-cli open ~/Documents/lettre\ de\ motivation.docx 
Opened document from '/Users/laurentvaldes/Documents/lettre de motivation.docx'. Session ID: c40b40108fca
➜  docx-mcp git:(feat/sse-grpc-multi-tenant-20) ✗ docx-cli revision-list c40b40108fca                  
{
  "track_changes_enabled": false,
  "total": 0,
  "offset": 0,
  "limit": 50,
  "count": 0,
  "revisions": []
}
➜  docx-mcp git:(feat/sse-grpc-multi-tenant-20) ✗ docx-cli track-changes-enable c40b40108fca true
Track Changes enabled. Edits made in Word will be tracked.
➜  docx-mcp git:(feat/sse-grpc-multi-tenant-20) ✗ docx-cli revision-list c40b40108fca            
{
  "track_changes_enabled": true,
  "total": 0,
  "offset": 0,
  "limit": 50,
  "count": 0,
  "revisions": []
}
➜  docx-mcp git:(feat/sse-grpc-multi-tenant-20) ✗ 

I am happy to test it out. I definitely would use it densely

I am happy to test it out. I definitely would use it densely

Frankly I had no time to test it extensively. Feel free.

@gabrielpacosta @valdo404

I have added a PR recently in the docx-editor that adds a MCP server:
https://github.com/pablospe/docx-editor/pull/7

I want this to work also in linux/macos, not only in Windows.

Hey @valdo404 I have been actively working on the same thing, happy to help in any possible way as well. The goal is to get something as close as possible to the Excel plugin and Claude code feeling, but for Word

@gabrielpacosta This is my goal too, where are you working on this? Maybe we can join forces :) Perhaps even creating a github organization, so we can all work in the same repo.

I have begun working on it, although the track changes support is not in the README. There is preliminary support, and I plan to improve it soon. Will update the README soon. I need testers for this project.

@valdo404 Just to let you know, this is a python library that supports track changes (works in all platforms):
https://github.com/pablospe/docx-editor/

It is using well known algorithms for diff calculation and change tracking, and JSON Patch semantics as well, and it is able to act in an agentic manner. I have seen that Anthropic has released official PPT and Excel plugins, but I plan to do it my way using office.js too.

Can you expand on this? What are your plans and if this will also work in linux?

just jumping in here to say this exists with claude cowork, and it is great, so would be nice if you also made it available to Claude Code desktop and Claude Code CLI!

Our law firm has developed a Claude docx plugin here: https://github.com/LegalRabbit-AI/legalrabbit-docx-claude-plugin -- it works with both Claude Code and Cowork.

It uses 2-5x fewer tokens compared to the Anthropic's docx skill because it maps the bloated docx format to HTML. AI would rewrite HTML, and the plugin would map HTML back to docx.

In contrast, the Anthropic's docx skill writes code, executes bash command, install python packages, and executes python code; this consumes a lot of tokens.

So far it works well for legal documents. If anyone is interested, please try it out and email us tanin@legalrabbit.ai