[Bug]: Sent prompts strike through text between two single tildes that the rich composer showed literally

apps/web/src/components/ChatMarkdown.tsxと、apps/web/src/components/chat/MessagesTimeline.tsxにあるChatMarkdownの呼び出しから始め、タイムラインのremarkプラグインと、apps/web/src/composer-rich-text.tsにおける単一チルダの動作を比較してください。issueの復元チェックで完了条件が定義されています。送信されたユーザーメッセージでは、単一チルダが取り消し線なしで表示され続ける一方、~~struck~~は引き続き取り消し線付きで表示されます。

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/web

Steps to reproduce

Summary

With the rich text composer on (the default), a prompt containing two single ~ characters in one paragraph, for example two home-relative paths such as ~/folder-a/... and (~/folder-a/...), shows both tildes as literal text while composing. After sending, the user message in the chat timeline renders everything between them with strikethrough and drops both tildes. The rich composer's markdown dialect and the timeline's markdown dialect disagree on single tildes, so the sent message misrepresents what the user typed. The stored message text and the text the provider receives are unchanged; only the rendering is affected.

Steps

1. On the build listed under Runtime or environment, with the rich text composer enabled (default), open any thread.
2. Type this prompt exactly, without backticks: Install the skill as ~/folder-a/skills/x, then follow the guide (~/folder-a/guide.md).
3. Observe the composer: both tildes are plain text, nothing is styled.
4. Send the prompt and look at the user message in the timeline.

Steps 1–4 with this exact string were not run in the app by the investigator; the in-app symptom comes from the reporter's screenshot of a real prompt with the same shape (see Actual behavior). The renderer and composer behavior were reproduced headlessly with the parser versions apps/web locks ([email protected], [email protected], [email protected], [email protected]), using the remark plugins that apply to sent user messages (which render with parseRawHtml={false}, so no rehype plugins run):

import React from "react";
import { renderToStaticMarkup } from "react-dom/server";
import Markdown from "react-markdown";
import remarkGfm from "remark-gfm";
import remarkBreaks from "remark-breaks";

const text = "Install the skill as ~/folder-a/skills/x, then follow the guide (~/folder-a/guide.md).";
console.log(renderToStaticMarkup(React.createElement(Markdown, {
  remarkPlugins: [remarkGfm, remarkBreaks],
}, text)));

Expected behavior

In rich text mode, the sent user message shows the tildes the composer showed: Install the skill as ~/folder-a/skills/x, then follow the guide (~/folder-a/guide.md). with both tildes visible and no strikethrough. The rich composer's inline-markdown parser (apps/web/src/composer-rich-text.ts) defines strikethrough as ~~ only and keeps a single ~ as literal text, stating that unmatched markers stay literal "so nothing the user typed is ever lost". That parser's guarantee is explicitly about the composer itself; applying it to the timeline rests on the inference that rich mode previews how the sent markdown will be formatted, since no code or test states that the composer and the timeline must render identically. Double-tilde strikethrough (~~struck~~) typed in the composer should keep rendering as strikethrough in the timeline. Plain-text composer mode, where every marker is shown literally by design, is out of scope.

Actual behavior

Supplied by the reporter: in T3 Code Nightly, a sent prompt containing ... as ~/[REDACTED]/gdp-ts, manifest-tracked, ... repo skill (~/[REDACTED]/SKILL.md) ... rendered in the timeline with roughly three lines, from just after the first tilde to just before the second, struck through and both tilde characters missing. By inference from that screenshot and the headless render below, the sample string in Steps to reproduce would render with /folder-a/skills/x, then follow the guide ( struck through and both tildes missing.

Headless run of the snippet above (local, locked versions) printed:

<p>Install the skill as <del>/folder-a/skills/x, then follow the guide (</del>/folder-a/guide.md).</p>

The composer's parser, run locally from main on the same string, returns a single unstyled span:

[{"text":"Install the skill as ~/folder-a/skills/x, then follow the guide (~/folder-a/guide.md).","marks":[]}]

Controls from the same local run: this is ~~struck~~ text renders <del>struck</del> in both the composer parser and the timeline renderer; files in ~/foo and ~/bar does not strike on web because the second tilde follows a space and cannot close; with remark-gfm configured as [remarkGfm, { singleTilde: false }] the report string renders literally while ~~struck~~ still renders <del>.

Evidence

• Expected source: apps/web/src/composer-rich-text.ts on main (header comment "Unmatched markers stay literal text so nothing the user typed is ever lost", RICH_TEXT_DELIMITERS.strike = "~~", and line 103 where a ~ run shorter than 2 cannot open a strike); rich mode is the default per composerRichTextEnabled in packages/contracts/src/settings.ts.
• Failure source: reporter's desktop-app screenshot of the sent user message, plus the local headless render above; the user message path is UserMessageBody → ChatMarkdown in apps/web/src/components/chat/MessagesTimeline.tsx (around line 4413), and ChatMarkdown passes bare remarkGfm in CHAT_MARKDOWN_REMARK_PLUGINS and CHAT_MARKDOWN_REMARK_PLUGINS_WITH_BREAKS (apps/web/src/components/ChatMarkdown.tsx lines 495–506), whose strikethrough extension defaults to singleTilde: true.
• Evidence provenance: observed
• Local verification: reproduced
• Reproduction completeness: complete

The observed primary evidence is the local headless render with the locked parser versions and the local run of the composer parser; the in-app rendering is supplied by the reporter's screenshot. Local reproduction covers the third-party remark plugins on the user-message path (remark-gfm, remark-breaks; UserMessageBody passes parseRawHtml={false}, so ChatMarkdown applies no rehype plugins); T3 Code's own remark plugins in ChatMarkdown and the app itself were not exercised locally, so the in-app symptom rests on the supplied screenshot.

Note: GitHub's own Markdown API (POST /markdown, mode=gfm) also strikes single-tilde pairs for this string, so the expected behavior here rests on T3 Code's own rich composer dialect, not on GitHub rendering parity.

Restoration check

Failing: in rich text mode, sending Install the skill as ~/folder-a/skills/x, then follow the guide (~/folder-a/guide.md). produces a user message in the timeline with a struck-through span and missing tildes. Passing: the same sent message renders both tildes literally with no strikethrough, matching the composer. Controls: a prompt containing ~~struck~~ still renders strikethrough in both the composer and the sent message, so strikethrough is not simply disabled; and the stored and provider-bound prompt text stays byte-identical to what was typed (no escaping or rewriting of ~ on send).

Additional context

Open PR pingdotgg/t3code#9021 ("fix(web,mobile): match GitHub strikethrough parsing") changes ChatMarkdown to { singleTilde: false } and patches the mobile renderer; it has no linked issue. Its stated premise that github.com only strikes double tildes did not hold for the Markdown API check above, but its web change would satisfy this report's restoration check. That PR also reports the mobile renderer striking single-tilde pairs more often (for example files in ~/foo and ~/bar); mobile was not investigated here and this report is limited to the web/desktop timeline. Whether assistant messages should also stop striking single tildes is a separate product choice; this report covers text the user typed in the rich composer.

Triage assessment

• Impact level: P3
• Assessment status: supported
• Impact basis: Only the rendered timeline view is wrong (struck span, hidden tildes); the stored prompt, the copy-message text and the text sent to the provider keep the original characters, so no data or workflow result is lost, though the sent message misrepresents what the user typed.
• Workaround status: available
• Workaround basis: Wrapping paths in backticks (`~/folder-a/guide.md`) renders them as inline code with tildes intact in the locally run renderer; it adds code-span markers to the sent text, and the path characters themselves are unchanged.

Impact

Cosmetic issue

Version or commit

T3 Code (Nightly) 0.0.46-nightly.20261005.2676; source inspected at main @ e22c8804346d4bd45a733803eda826e04e3bbd74

Environment

macOS 27.0, T3 Code (Nightly) desktop app, Claude provider

Logs or stack traces

No response

Screenshots, recordings, or supporting files

No response

Workaround

Wrapping paths in backticks (`~/folder-a/guide.md`) renders them as inline code with tildes intact in the locally run renderer; it adds code-span markers to the sent text, and the path characters themselves are unchanged.