Deepseek's coding harness and the dreaded "Content Exists Risk"

I regularly use Deepseek’s coding harness, which is designed to run locally for coding tasks. It eshews the TUI-centric approach of others, and adopts a purely web-based interface.

Recently, I encountered an odd issue. While the agent was working, it would suddenly stop working and display this cryptic message:

• This turn failed Content Exists Risk (request_id: 7760df0b-57fe-4d2d-b854-d55b19a55a79)

Unfortuantely Deepseek have disabled issues reporting on their GitHub repository, so there was nowhere directly to look for a solution, or to see if others were identifying this issue, and it was a recently introduced issue. The whole coding harness is still very much alpha software, so it could be down to anything.

I carried on, but I kept hitting this bug more and more, so I decided to trace it down as much as I could. It turned out that the issue would trigger any time it read a documentation index.md file in my repo. This was a fairly high traffic documentation directory, and it would generally need to write to this index at the end of the workstream. It was also unrecoverable without losing all of the last turn’s work. Once the turn history was poisoned with whatever the file contained that was triggering the issue, that was it. Game over.

Through a series of tedious bisections and debugging, I was able to narrow down the issue to a specific piece of summary:

| 2026-10-08-same-person-book-duplicates.md | In-book record consolidation, four known cases. Each case: two active book-level entries under different labels that the global layer already ties to one shared node, but the book pass never proposes combining them — so each book carries split profiles and split connection maps for a single node. Owner view: the gap is in the book-level combine step; the global layer only surfaced it. Four census-checked pairs on file, repro query attached, cause analysis done (label surfaces never intersect, zero shared scenes, no family-bridge leg, short-entry entries skipped — both-label pair included). Owner decision 2026-10-09: option A (global consensus) out of scope as fix — global sync runs too late; the four matches become the labeled sample. Trace done 2026-10-09: no pair shares a scene; K-type ready for option C (edge-overlap evidence in DB), M/C-type needs option A restored as fallback, E.P.-type likely resolved via name-source handling. leonidas re-scan #2 (2026-10-09, fresh): E.P.-type combined, verified (5b2c2ae6). Remaining: option C on K-type, then option A fallback for M/C-type. Known-case set grows with global matching — cheap window is now. Out of scope: global-layer changes, automatic combining; the four pairs are the acceptance fixtures. | High | M |

I’ve no idea why this summary tripped the safety fence. Some of the language could be risky, like impersonation, exhausted, failure, halt, budget. I’ve changed the summary description, and the issue is no longer occurring. It’s all very mysterious, I’m just documenting it here for future reference.