fix(dashboard): recognise Windows paths in the markdown path chip

[iamwhatever]

Problem / Motivation

On a Windows gateway, clicking a file path the agent just wrote in chat copies the
path to the clipboard instead of opening the file in the sidebar viewer. Reported
by a Windows desktop user on the latest version.

It affects every Windows absolute path, so on Windows the path chip — the
normal route from "the agent mentioned this file" to "the file is open in front of
me" — has never worked. Nothing looked broken, which is why it went unreported for
so long: the span still rendered as a chip and still did something on click, just
the wrong thing.

Why it matters

Two costs, one of them silent.

The visible one: every Windows user loses the click-to-open affordance entirely and
gets a clipboard write they did not ask for, with no way to tell that a different
behaviour was intended.

The silent one: the same pre-filter admitted //host/share/x.txt as a path
candidate, so rendering a message containing one made the dashboard ask the gateway
to stat it. On Windows that stat is an outbound SMB connection offering the host's
NTLM credentials. Since chat markdown can carry untrusted text (a fetched page, a
quoted file), that was a credential-leak vector reachable from rendering alone. It
is closed here — see the fourth bullet under What changed.

What changed (motivation → approach → change)

Symptom — a Windows path chip copies instead of opening.

Root cause — isPathCandidate in website/src/components/MarkdownRenderer.tsx
is the pre-filter that decides whether an inline-code span is worth spending a stat
probe on. Its PATH_SHAPE_RE required a forward slash and admitted neither a
backslash separator nor the colon in a drive prefix, so C:\Users\me\notes.md,
C:/Users/me/notes.md and src\main.py all failed it. No candidate means no
probe; no probe means usePathKind never reports file/dir; and InlineCode
then falls through to the CopyableCode branch, whose click handler copies. The
copy was never a fallback for a failed path — it is the generic inline-code
affordance, and Windows paths were never recognised as paths at all.

The rest of the chain was already Windows-aware, which is what makes this a
one-place fix: fileReadUrl.ts::isAbsolute already classifies drive and UNC
shapes, MdImage already routes a drive-qualified src through
WINDOWS_ABS_PATH_RE (issue #3497), and splitLineRef, activatePath,
FilePathMenu and /api/reveal are all separator-agnostic. Only the pre-filter
was POSIX-only.

Change — five parts, all in the pre-filter:

• PATH_SHAPE_RE accepts either separator, which is what lets a relative
  Windows path (src\main.py, .\src\main.py) reach the probe.
• A new WIN_DRIVE_PATH_SHAPE_RE carries the drive-rooted form the general shape
  structurally cannot: a drive prefix puts its colon before the first separator,
  while the general shape allows a colon only in the last segment, where it serves
  file:447.
• Parentheses are admitted in a path segment, on both platforms. C:\Program Files (x86) is one of the most-trodden directories on Windows, so excluding it
  would have left the defect in place for a large share of real paths — the first
  revision of this PR did exactly that, and the GPT review lane caught it.
  /Users/me/App (old).md is the same filesystem convention, so it is admitted
  too rather than shipping an asymmetry that would just be the next report. A
  closing paren may also end a path, so a directory named App (old) classifies.
  This widens the character repertoire, not the positive-signal rule, so
  parenthesised prose (foo/bar (baz)) is still refused.
• A new UNC_PREFIX_RE (/^[/\\]{2}/) refuses any two leading separators,
  checked before every other rule because the others would readmit it — the
  extension rule matches \\\\host\share\x.txt and the leading-/ rule matches
  //host/share/x. Per-CHARACTER, not per-spelling: Windows reads any two leading
  separators as a UNC root regardless of kind or order, so enumerating \\\\ and
  // would leave the mixed pairs \\/host\share\x.txt and /\\host\share\x.txt
  admitted, and those resolve to the same share. This is the same line three other places in the
  codebase already hold (WINDOWS_ABS_PATH_RE for image src, MdAnchor for a
  decoded // link destination, and the producer/consumer asymmetry documented on
  WIN_PRODUCER_PATH_RE); the chip was the one consumer-side predicate that had
  not adopted it.
• Rootedness becomes a positive signal for Windows too, reusing the existing
  WINDOWS_ABS_PATH_RE rather than restating it, so C:\Windows needs no
  extension exactly as /Users does not. The extension gate now takes the
  basename across either separator, so a dotted directory (project\v1.2\notes)
  is no longer misread as an extension on the file.

Why widening the separator is safe. The existing "a bare two-segment
identifier with no extension is rejected" rule does the work: a \-joined
non-path carries no extension, so \n, HKEY_LOCAL_MACHINE\Software\Foo and
CORP\alice are all still refused — on every platform, since the pre-filter
cannot know the gateway's OS — and no request is issued for them. The probe
remains the decision; this only widens what is worth asking about.

Deliberately not in scope. utils/terminalCompletion.ts and
MarkdownPanel.tsx's isAbs carry the same POSIX-only assumption on other
surfaces. They are separate behaviours with their own tests and are left alone
rather than folded in here; see Pattern harvest.

Tests

15 new tests in website/src/test/MarkdownRenderer.test.tsx, 122 passing in that
file (was 107).

Ten pin the pre-filter decision in isolation: drive-rooted paths in both separator
spellings; a drive-rooted path with no extension (and a bare C:\ root); UNC
refused in every spelling — both same-kind pairs, both MIXED pairs, and the Win32
extended-length prefix — with /server/share/report.txt still accepted to show one
slash is unaffected;
explicitly-relative and extension-bearing backslash paths; Unicode segments under
a drive root; backslash-joined non-paths still refused; the basename read across
either separator (project\v1.2\notes vs project\v1.2\notes.md); parenthesised
segments on Windows and on POSIX; and parenthesised prose plus a parenthesised UNC
share still refused.

Five pin the rendered consequence, which is what the report was actually about: a
drive-qualified path renders as a data-path-kind="file" chip and routes a click
to onFileOpen; C:\Program Files (x86)\app\config.json does the same; both drive
spellings get probed while a backslash UNC path never does — the stub would have
answered file for it, so the absent request is the SMB guard's assertion; a
Windows file:line citation carries its line through; and backslash text that is
not a path issues no probe at all and stays a copy chip.

Reverting only the component hunks and re-running turns 12 of the 15 red. The
three that stay green are pure negative guards, which held before the change too.

Five neighbouring suites that render chips or resolve Windows paths
(MarkdownRendererCoverage, MarkdownRenderer.contextmenu,
MarkdownRenderer.windowsImagePath, usePathKind, fileTokens) pass unchanged:
115 tests. tsc -b clean; eslint at its existing 597-warning ceiling, unchanged.

Manual verification

Not performed — it is not reachable from a macOS host, and that is inherent to
the bug rather than a shortcut. The chip's affordance is gated on the gateway's
filesystem answering the stat probe, so confirming the fix end to end requires a
Windows gateway: on macOS no Windows path resolves, and the chip correctly stays
inert. The 15 tests above stand in by driving the same
pre-filter → probe → chip → onFileOpen chain with the probe stubbed.

What still wants a human on Windows: open a chat, have the agent write an absolute
path, and confirm a left click opens the sidebar viewer at that file (and at the
right line for a path:42 citation) rather than copying.

Screenshots / video

Waived by the no-screenshots label, applied by the maintainer.

There is a rendered delta — on a Windows gateway the span gains the file glyph
and the confirmed-chip styling — but it is unreachable from the authoring host for
the same reason manual verification is: the chip only renders confirmed once the
gateway stats the path, and a macOS gateway stats no Windows path. Booting an
isolated instance to capture it was attempted twice (the repo dev stack and
kirocrew pod up) and both are blocked by sandbox permission errors on this host.
Nothing about the chip's appearance is new; it is the existing confirmed-path
chip, already visible throughout the product for POSIX paths.

Related Issues

no linked issue: reported directly as customer feedback; no matching open issue
found (searched open issues for the windows/path/chip/copy terms).

Pattern harvest

Rule candidate: review-prompt
Pattern: a syntactic pre-filter over filesystem paths written against one
separator convention, in a codebase whose gateway can be Windows.

This one does generalize, and it has a specific shape worth catching: the shape
predicate was POSIX-only while every consumer downstream of it was already
Windows-aware, so the bug hid behind a chain that otherwise handled Windows
correctly. utils/terminalCompletion.ts:238 and MarkdownPanel.tsx:74 carry the
same assumption today on other surfaces.

The second half is the one I would actually encode as a rule: when a
path-shaped predicate is widened, check whether a sibling predicate narrowed it on
purpose. Adding Windows support here naturally admitted UNC, and UNC is excluded
elsewhere in this codebase for a documented security reason — the widening would
have quietly reopened an SMB credential-probe vector that the image and link paths
both defend against.

A third, smaller lesson from the review round: a character-class allowlist over
real filenames is easy to under-build. Parentheses were missing from the first
revision, and C:\Program Files (x86) is common enough that the fix would have
read as still broken to the very user who reported it.

Checklist

• At most two commits (one is the norm), with a Conventional Commits title (feat|fix|docs|refactor|perf|test|chore|ci|build|revert: ...)
• Existing tests pass and new tests added for new functionality
• Self-review completed; code follows project style guidelines
• Documentation updated (if applicable) — behaviour is documented in the predicate's own comments, which is where the existing rationale lives
• No secrets, credentials, or internal references in the diff

[github-actions]

UX Review (Fable 5) — ✅ PASS

UX-level review of a44b51ac10f1047a79d78df63697e0901186d356 — updated in place on each push. A BLOCK verdict blocks PR readiness; PASS/CONCERNS are advisory.

UX-Verdict: PASS

Purely widens path recognition behind the existing stat-probe gate; Windows users gain the intended click-to-open chip, and no visible surface, string, or affordance changes.

[UX-REVIEWED] a44b51a

[github-actions]

Design Review (Fable 5) — ✅ PASS

Design-level review of a44b51ac10f1047a79d78df63697e0901186d356 — updated in place on each push. A BLOCK verdict blocks PR readiness; PASS/CONCERNS are advisory.

Design-Verdict: PASS

Root-cause fix at the single POSIX-only predicate in an otherwise Windows-aware chain, with the UNC/SMB widening hazard explicitly closed and pinned by tests.

Suggestions

• The SMB guard now lives in four parallel client-side predicates; the connection actually happens at the gateway's stat, which non-chip callers can reach — a backend refusal of host-naming shapes on that endpoint is the durable single point (separate follow-up, not this PR).

[DESIGN-REVIEWED] a44b51a

[github-actions]

First Principles Review (Fable 5) — ✅ PASS

Premise-level review of a44b51ac10f1047a79d78df63697e0901186d356 — why this exists and whether the shipped surface is the smallest honest version. Updated in place on each push. A BLOCK verdict blocks PR readiness; PASS/CONCERNS are advisory.

All claims verified. The //host/share/x spelling did pass the old pre-filter (optional (?:\.{0,2}\/)? plus the leading-/ signal), so the UNC refusal closes a real pre-existing probe path; the fix's own \\ widening would have readmitted UNC via the extension rule, making the refusal required, not a rider. Counts: isPathCandidate has 1 real consumer (MarkdownRenderer.tsx:875); the sibling POSIX-only predicate MarkdownPanel.tsx:74 is the one unfixed sibling and the author declares it out of scope; terminalCompletion.ts uses backslash only as shell-escape, a different domain.

First-Principles-Verdict: PASS

Every item traces to the reported defect or the named external-content boundary, reuses the existing Windows predicate, and counts its one deferred sibling.

What this change ships

Intent: make clicking a Windows path the agent wrote open the file instead of copying it — a FIX.

1. Drive-rooted Windows paths (C:\…, C:/…) now open on click — justified (the reported defect).
2. Relative backslash paths (src\main.py, .\x) now chip — justified, same defect.
3. Extensionless drive-rooted paths (C:\Windows, bare C:\) chip, mirroring the POSIX rooted rule — justified.
4. UNC refused in every spelling; //host/share/x no longer probed even on POSIX — justified: external-content boundary, and the \\ widening would readmit it via the extension rule.
5. Punctuation ' ! # % = + , ( ) [ ] { } now legal in chip paths on both platforms — rides along, but cause-level: ends the per-report allowlist churn, prose refusal test-pinned.
6. Dotted directory (project\v1.2\notes) no longer misread as a file extension — justified, fix-internal.
7. Rootedness signal reuses existing WINDOWS_ABS_PATH_RE (utils/urlTransform.ts:24, already imported) — justified reuse, no second spelling.

Watch

• One counted unfixed sibling of the POSIX-only root cause: MarkdownPanel.tsx:74 (isAbs = filePath.startsWith('/')), grepped startsWith('/') under website/src. The description declares it out of scope; accepted-and-deferred, not a demand.
• Item 5 widens beyond the two review-reported characters and onto POSIX; the widening is bounded by the unchanged positive-signal rule, so no subtraction is warranted.

[FIRST-PRINCIPLES-REVIEWED] a44b51a

[github-actions]

Opus 4.8 Review — ✅ no blocking findings

Reviewed a44b51ac10f1047a79d78df63697e0901186d356 — this comment is updated in place on each push.

Review details

No findings.

[OPUS-REVIEWED] a44b51a

Verdict parsed from the review's SHA-scoped output markers for commit a44b51ac10f1047a79d78df63697e0901186d356.

False positive or not applicable? A repository writer can comment:
/ai-review override fable a44b51ac10f1047a79d78df63697e0901186d356: <one-sentence reason>

[github-actions]

GPT 5.6 Review — ✅ no blocking findings

GPT 5.6 completed its review of a44b51ac10f1047a79d78df63697e0901186d356 and found no blocking issues.

This comment is updated in place on each push.

Review details

No findings.
[GPT-REVIEWED] a44b51a

False positive or not applicable? A repository writer can comment:
/ai-review override gpt a44b51ac10f1047a79d78df63697e0901186d356: <one-sentence reason>

[NicholasRBowers]

Tier 1 auto-approve: fix (2 files). Criteria: no conflict, no requested changes, security path denylist clean, design-doc gate clean, SAST annotations clean, security checklist all-NO, AI reviewers green. Category: fix with clear root cause -- markdown path chip regex extended to recognise Windows drive/UNC paths, with test.

[iamwhatever]

• C:\Program Files (x86)\app.txt fails the filename whitelist and still falls back to copying (span=3a1b1d5e17c6) — fixed in 70bc07d.

Legitimate and in scope: this is not a hardening request, it is the reported defect still being present. C:\Program Files (x86) is one of the most-trodden directories on Windows, so shipping without it would have read as "still broken" to the user who reported the bug.

Fixed by admitting parentheses in the segment classes of both PATH_SHAPE_RE and WIN_DRIVE_PATH_SHAPE_RE, and allowing a closing paren as the terminal character so a directory named App (old) classifies. Admitted on the POSIX side too (/Users/me/App (old).md) rather than only on the Windows shape — the two shapes describe one filesystem convention, and an asymmetry that fixed Windows while leaving POSIX failing would just be the next report.

UNC rejection is retained exactly as you asked: UNC_PREFIX_RE runs ahead of both shape tests, so parentheses cannot smuggle a host-naming path past it — pinned by expect(isPathCandidate('\\\\server\\Program Files (x86)\\x.txt')).toBe(false).

Scope held to the character repertoire, not the positive-signal rule, so parenthesised prose with no root and no extension is still refused (foo/bar (baz), and/or (maybe) — both pinned). 4 new tests; 3 of them are red against the previous head.

[iamwhatever]

• UNC_PREFIX_RE is the fourth local restatement of the "refuse host-naming shapes" line — hoist it next to WINDOWS_ABS_PATH_RE — accepted-and-deferred to #7990.

Agreed on the direction, and the count is right: WINDOWS_ABS_PATH_RE, MdAnchor's !decodedHref.startsWith('//'), WIN_PRODUCER_PATH_RE and now UNC_PREFIX_RE all hold the same line with no single owner, which is how one of them eventually drifts.

Deferred rather than done here on proportionality: hoisting today produces a shared export in utils/urlTransform.ts with exactly one consumer, because the two adopters your suggestion names — terminalCompletion.ts and MarkdownPanel.tsx — have not been fixed yet. The hoist earns its place in the change that adds the second and third consumers, and doing it then also avoids guessing the shared signature from a single call site.

Tracked as #7990 (deferred-finding, assigned, Due: 2026-10-03), which covers both sibling predicates and the hoist as one unit of work and quotes your suggestion as its rationale. Not security-deferral: the vector this PR actually closes is closed in this PR — UNC_PREFIX_RE refuses both spellings ahead of every other rule, and the pre-existing //host/share/x admission on main is fixed here, not deferred.

[iamwhatever]

Fixed — website/src/components/MarkdownRenderer.tsx

• UNC_PREFIX_RE refused only same-kind separator pairs, so a mixed-separator UNC path reached the gateway stat probe (span=45e0c12ab71c)

Correct, reachable, and the guard's own docstring already argued for the fix it
did not implement: "Windows resolves the forward-slash spelling to the same
share, so refusing only the backslash form would leave the vector open under a
different coat of paint." That reasoning does not stop at two spellings —
Windows reads ANY two leading separators as a UNC root, of either kind and in
either order — so enumerating \\ and // left \/host\share\x.txt and its
/\ mirror admitted. The leading separator is then eaten by the relative-prefix
group, PATH_SHAPE_RE matches, EXT_RE sees .txt, and the probe fires a real
HEAD /api/file-read at the gateway — an outbound SMB connection offering the
host's NTLM credentials, from nothing but rendering a message.

Worth noting this shape is introduced by this diff: the pre-diff predicate
required a forward slash and admitted no backslash separator, so a mixed pair
could not form at all. It is this PR's own regression, not a pre-existing gap.

Taking the prescribed fix exactly as written, because it is the minimal one and
it changes the rule from per-spelling to per-character:

-const UNC_PREFIX_RE = /^(?:\\\\|\/\/)/
+const UNC_PREFIX_RE = /^[/\\]{2}/

Four assertions added to the existing REFUSES UNC case cover both mixed orders
against both trailing separator styles. Proven RED first: with the test change in
place and the source reverted, the case fails expected true to be false; with
the one-character-class fix it passes. 122/122 in the file, tsc -b and
eslint src --ext .ts,.tsx clean.

The docstring no longer enumerates spellings — it states that the character class
is the point and names the mixed pair as the shape enumeration misses, so the next
reader cannot re-derive the narrower regex from the comment.

Also on this head: Backend Tests (Windows) (3) failed on
test_sel.py::TestCrossProcessSafety::test_concurrent_processes_keep_one_unbroken_chain
(expected 24 entries on disk, found 23). This diff touches two files, both under
website/src/, and that is a backend cross-process HMAC-chain test with its own
history of races (#2497, #6081). Not this PR's, and not chased here.

[iamwhatever]

• "_.@~() -" rejects valid paths such as C:\Users\O'Neil\notes.md, so no probe occurs and clicking still copies (span=3a1b1d5e17c6) — fixed in a44b51a.

Legitimate, and the same completeness class as the parentheses finding you raised last round: an apostrophe is legal in a filename on both platforms and O'Neil is an ordinary name, so the character class left the reported defect in place for those users.

Rather than add ' alone, the punctuation set is now stated once as a decided boundary — because two consecutive rounds each finding one more legal character is the signature of an allowlist being discovered one bug report at a time, and a third round was the likely outcome. The rule: admit every character legal in a filename on BOTH platforms that is not a shell control operator, applied to both shape regexes. Newly IN: ' ! # % = + , [ ] { } alongside the existing ( ). Deliberately OUT, and now documented in-code as the reason the anchored shape still rejects commands and URLs: $ and backtick, & ; |, < >, ", ? *, and : outside the last segment where it serves file:447.

Widening the repertoire does not widen the positive-signal rule, so punctuated prose still carries neither a root nor an extension and is still refused — pinned by foo/bar (baz), and/or (maybe), and a dedicated case per excluded operator ($HOME/x.txt, a&&b/c.sh, cmd;rm/x.sh, a|b/c.txt, a>b/c.txt, glob*/x.txt, what?/x.txt), every one of which carries an extension so only the class refuses it.

17 new tests in the file (124 passing, was 107); reverting the component hunks turns 13 red.

[bolichen97]

Open PR relationship audit

This is a consolidated, point-in-time code-level audit note. It compares complete merge-base diffs and current/merged code; it does not treat a shared topic as duplication or partial coverage as completion.

Relationship findings

• PR #8012 is OVERLAPPING relative to this PR. The goals differ or the implementations can complement each other; this is not a duplicate claim. Recommended action for PR #8012: CONTINUE_DEVELOPMENT. The merged sibling covers a different predicate and does not implement either behavior this PR adds, but it also fixes the UNC guard by shape after review rejected the alternation form this PR ships; align the regex with main's /^[/\]{2}/ (and have the hoisted export be the one thing every call site imports) before merge. Files: website/src/components/MarkdownRenderer.tsx, website/src/utils/urlTransform.ts.

No PR, Issue, label, branch, or review state was changed by the relationship-note portion of this audit.