Code Mode crashes on tool descriptions containing {{ }} — fix included

[marcschraepler]

A tool description containing a literal {{ }} (e.g. Composio's COMPOSIO_REMOTE_WORKBENCH, which documents escaping braces by doubling them) crashes Code Mode with malformed prompt variable reference "{{ }}" in section "tools:sdk".

The description reaches the model through the tools:sdk prompt section, which renderPrompt interpolates for {{variable}} references — an unescaped {{ throws as malformed instead of being treated as literal prose.

I have a fix ready: split {{ into { { at the existing sanitize point in both renderers (ts-types.ts's docLines, py-types.ts's describe()), the same place that already escapes */ and quotes/backslashes for the same reason. Added regression tests for both renderers (64/64 passing), and reproduced live against the Code preset with an MCP server mounted to confirm the crash is gone.

Full diff here since PRs aren't open yet: https://github.com/marcschraepler/deepseek-harness/tree/fix/code-mode-brace-escaping

Happy to open a proper PR once that's available, or paste the diff inline here if that's more useful.

[173787247]

[marcschraepler]

Thanks for looking! Just to clarify - this isn't a connectivity/spawn issue (tools not being called, stdout/stderr, PATH, etc.). It's a text-escaping bug in the prompt renderer itself: any tool description containing a literal {{ - regardless of which MCP server it comes from - crashes Code Mode's tools:sdk section, because renderPrompt tries to interpolate it as a {{variable}} reference. Repro steps and the fix (diff linked above) are in the original post; happy to add anything else that'd help review it.

[argszero]

Confirmed against the source at cd5ef81481 (0.1.2-alpha.1) — your diagnosis and fix location are correct, and this is the second independent report of the same defect. Family closure:

1. Same root cause as #3454. Reported 2026-08-19 with drawio's MCP ({{hexagon}} mermaid syntax) in code-mode presets: renderToolsSdk embeds every registered tool's raw description into tools:sdk, and interpolate() strictly scans {{name}} with no escape. Your {{ }} (empty pair) throws the "malformed prompt variable reference" variant; #3454's {{hexagon}} throws the "unknown prompt variable" variant — both come from the same scan in core/system-prompt (both messages are pinned in system-prompt.spec.ts:384/:547), and both are fixed by the same escape.

2. Era check: still live at alpha.1. Both sanitize points remain unescaped:

• core/tools/src/ts-types.ts:32-36 — docLines collapses whitespace and escapes */ only
• core/tools/src/py-types.ts:241-247 — docLines escapes \ and " only, and delegates to describe({ description }) — so your two-site fix (ts-types docLines + py-types describe) is exactly the right pair

3. The choke-point argument holds. docLines is called at both ts-types.ts:164 (property descriptions) and :302 (top-level tool description) — one escape covers every embedding path into tools:sdk. An interpolator-level fix (fenced-code skip, etc.) would be the wrong layer: it would silently change legitimate {{var}} substitution in harness-authored sections. Sanitizing at the generation boundary keeps harness-authored text strict while neutralizing untrusted third-party descriptions.

4. Safety check — the escape cannot break legitimate interpolation. I grepped first-party tool descriptions for raw {{: zero hits. No registered-variable substitution depends on {{ inside a tool description (the documented variable mechanism is section-level, not description text). Worth a short code comment saying so, so a future {{model}} in a first-party description doesn't get silently escaped.

5. Regression shape (matches what I'd blueprint from #3454): a fake tool whose description contains {{hexagon}} (and a {{ }} empty-pair variant, to pin the malformed branch), assembled in code/both presentation mode → assert no throw and the literal text survives. Your 64/64 plus the live Code-preset repro already cover the real path.

This was #25 in my PR-ready blueprint queue from the #3454 thread — if the harness ever reopens PRs, this is a natural first landing.

[marcschraepler]

Really appreciate the deep-dive, especially confirming it against current master and tracing both throw branches back to the same interpolate() scan — that's exactly right.

Pushed both suggestions:

• Added the {{hexagon}}-style regression case (the "unknown prompt variable" branch, distinct from the "malformed" branch my original {{ }} case covered) for both renderers.
• Added a comment at each sanitize point noting this is untrusted third-party tool text, not a harness-authored template, and confirming (via grep) that no first-party description currently relies on {{ surviving into tools:sdk.

68/68 tests passing now. Same branch: https://github.com/marcschraepler/deepseek-harness/tree/fix/code-mode-brace-escaping

Thanks also for the pointer to #3454, good to know this is a confirmed, independently-reported family rather than a one-off. Ready to open a PR whenever that's possible.

[173787247]

Sorry about the earlier empty/wrong reply — this is not an MCP spawn/PATH/stdout issue.

You're right: any tool description that contains a literal {{…}} gets embedded into the tools:sdk prompt section, and renderPrompt / interpolate() treats it as a template variable. Empty {{ }} becomes "malformed prompt variable reference"; something like {{hexagon}} becomes "unknown prompt variable". Same scanner, two throw messages. That matches Composio-style doubled braces and the drawio case in #3454.

Until a core escape lands (sanitize at the tool-description boundary in ts-types / py-types, as in your branch — not inside the interpolator), practical workarounds:

1. Prefer Standard (or any non-Code/PTC presentation) for sessions that mount MCP servers whose descriptions contain {{.
2. Or temporarily disable / avoid those specific tools so their descriptions never enter tools:sdk.
3. Do not “fix” it by rewriting MCP docs in the running session — the next schema refresh will bring {{ back.

Your fork branch looks like the right fix shape: escape untrusted third-party description text at generation time, keep harness-authored {{var}} sections strict. Happy to see that land when PRs reopen.

[marcschraepler]

No worries at all, thanks for circling back with the correction. The workarounds are spot-on, especially the warning against editing MCP docs mid-session (good catch, that wouldn't survive a schema refresh). Useful for anyone hitting this before the fix lands.