The Claude Cowork file truncation problem

This image was created using an AI image creation program

AI Ate My Homework

If you are here because your files are being truncated you might want to skip to the fix.

An adage holds that a great deal of the value of a business lives in the minds of its employees and in its processes and procedures. So, if you are thinking of selling at some point, get the processes defined early and keep them up to date.

In the age of AI with fewer employees, more value is stored in process and procedures, and these should be usable by both humans and AI. We wanted to get the procedures defining how the business operates down in writing from the beginning. This introduces a familiar pain point: keeping documents up to date and document referencing up to date. Humans still tend to print things out, so version numbering is important.

This is a job AI should be good at. Every time we change a document, we put it in an ‘inbox’, Cowork checks for changes, bumps the version number and the associated version number in cross-referencing documents. Easy-peasy you would think.

Unfortunately, after using this process for a day or so, we discovered that the AI had been quietly dropping a sentence or two from the end of files it was processing.

I have worked in many computer languages. Saving and editing files has never been a problem. Either things save fine or you get an error. This eating away at a file slowly was a new one on me.

The first fix: treating the symptom

I discussed it with Claude and Claude suggested adding a completeness check to files after major edits. Check the end of the file is as expected. If content has been eaten by the AI gremlins, add it back on. I went along with this. It seemed reasonable.

Claude also added a rule: edit files in place rather than replacing them wholesale. Find the specific text, change it, leave everything else alone. This was the right direction, but I left some ambiguity. For cases where a full replacement was “genuinely necessary,” the tool could still rewrite the entire file, provided it verified the result afterward. Ambiguity and LLMs do not play together well.

A half-@ssed hack

The next time I ran the skill, it truncated files again. Predictably, towards the end of the day when frustration was rising and time and patience were quickly diminishing.

The inbox document, the one being processed, was fine. The completeness check caught nothing wrong with it. The damage was in the cross-referenced files. Other documents in the repository that needed tiny updates because a version number had changed.

These were five-character edits. Changing “0.3” to “0.5” in a single table row. The smallest possible change to a file. Yet whole sections at the end of those files had vanished.

My completeness check had not caught this because it was only checking the primary document. The cross-referenced files were being updated silently, and nobody was verifying them at all.

Gremlins… “I am the only one who sees them!”

Then, in the middle of my William Shatner in classic Twilight Zone flashback, it occurred to me. We were addressing the symptom, not the bug. This is a newbie coder error. I had lazily allowed Claude to suggest a fix without thinking about things properly. I stirred from my doze and told Claude that this is not good enough. This way lies technical debt.

Supervising LLMs coding can be like having a junior coder on the team who has somehow learned the intricacies of lots of different computer languages without ever learning the basics of good software engineering. The big difference is that Claude does not resent being told that. Well, not so far. I will get back to you on this once the AIs take over the world.

The diagnosis

A surgical edit, one that finds a specific string and replaces it, cannot lose the end of a file. It does not touch the end of the file. It only touches the characters it was asked to change. The rest of the bytes stay on disk untouched.

The tool was not doing surgical edits. It was regenerating the entire file. Even for a five-character change, it was reading the file, producing a completely new version with the change folded in, and writing the whole thing out from scratch.

The write operation underneath this is “truncate the file to zero, then write the new content.” If the model producing that new content does not emit every single line, or the write is not fully flushed, you get a file that is shorter than it should be. The new content simply stops before the end. The tail is gone.

This is why the completeness check was the wrong primary defence. I was trying to catch a failure after it happened, when the correct move was to make the failure impossible by construction. You do not hack the symptom. You fix the bug.

The real fix

The rewritten specification allows exactly two write modes. There is no third option.

Mode A: in-place edit. For any change expressible as a localised substitution (a version bump, a history row, a status change, a cross-reference update) locate the specific text and replace only it. The unchanged remainder of the file is never re-emitted. This is the default and covers nearly every change the skill makes.

Mode B: replace-and-swap. For a genuine whole-document replacement that an in-place edit cannot express, write the completely new content to a separate temporary location. Verify it is whole. Only then move it into place over the previous file. The previous file is never removed until the new content has been written and verified in full.

Neither mode reproduces a file’s unchanged content and then overwrites it. That excluded third path is the truncation mechanism. Removing it from the available modes prevents the failure by construction rather than catching it afterward.

Third time is a charm

With the two-mode constraint in place, I ran the skill again. The completeness check caught two more truncations.

This time the tool was not regenerating entire files. It was using Cowork’s built-in Edit tool, which should have been doing Mode A surgical edits. It was not. The Edit tool re-emits surrounding file content as part of making a change. It looks like a surgical edit from the outside. Underneath, it is reproducing content it was not asked to touch, and dropping the tail in the process.

The smoke alarm did its job. It caught both truncations before they reached the repository. But the lesson was uncomfortable. I had fixed the obvious regeneration problem and walked straight into the same failure class wearing a different hat.

The fix was to bypass the Edit tool entirely. Instead, the skill now reads the file, replaces the target text in memory using a direct string replacement, and writes the result back through a basic file-write operation. This read-modify-write path changes only the intended bytes. It never re-emits content it was not asked to change.

The constraint is not “use in-place edits instead of regeneration.” It is “use a mechanism that provably only reads, replaces, and writes.” Any tool that re-emits surrounding content as part of an edit is a truncation risk, regardless of what it calls itself.

The fix (summary for developers)

If you are using an AI tool to maintain files and you are seeing silent truncation, the cause is almost certainly the tool regenerating entire files from model output rather than making surgical edits.

A probabilistic model does not guarantee it will emit every line of a file it is reproducing.

The fix is a hard constraint on how writes happen:

• For small changes (version numbers, cross-references, status fields): use in-place string replacement. Find the old text, replace it with the new text, do not touch anything else in the file
• For wholesale replacements: write the new content to a temporary location, verify it is complete, then swap it into place. Never overwrite the original until the replacement is verified
• Never let the tool regenerate a file from scratch and overwrite the original. This is the path that truncates. When the model does not emit every line, your file gets shorter and nothing reports an error
• Be aware that even tools labelled as “edit” or “in-place” may re-emit surrounding content underneath. Cowork’s built-in Edit tool did this and truncated twice before we caught it. If your in-place edit tool is still truncating, the tool itself is the problem. Use a read-modify-write approach instead: read the file, replace the target string in memory, write the result back through a direct file-write primitive

Add a completeness check as a backstop: after every write, verify the file ends on the right section and has not unexpectedly shrunk. But treat this as a smoke alarm, not the load-bearing safety mechanism. The prevention is in the write constraint. The check is there in case the prevention somehow fails.

This applies to every file the tool touches, not just the primary file being processed. In my case, the truncation hit cross-referenced files that were getting five-character updates. If your tool updates secondary files because of a primary change, those secondary files need the same write discipline.

The smoke alarm principle

I still run the completeness check on every file the skill writes. It fired twice more after the two-mode fix, catching truncations from the Edit tool before they reached the repository. Since switching to the read-modify-write approach, it has been silent. That is where we want it.

A good safety mechanism is one you hope never sounds. If your safety mechanism is firing regularly, it is not safety. It is a workaround for a broken process. Fix the process.

This applies far beyond file editing. Wherever you are using AI tools, ask yourself: is my safety mechanism preventing the failure, or detecting it after the fact? If it is the latter, you are one missed check away from silent damage.

The general lesson

When an AI tool “edits” your document, find out what it is doing underneath. Is it making a targeted change to specific text? Or is it regenerating the entire document and writing it back?

Supervising AI tools is like supervising that junior coder. They know the syntax of every language but not the engineering principles underneath. They will choose the quick, plausible path over the correct one unless you constrain them. The difference is that a junior coder’s mistakes are usually visible. A truncated file looks like a slightly shorter file. Nobody notices until the missing content matters.

The frontier is full of tools that look reliable until you check.

Check.