PowerShell terminal: file paths and multi-line URLs are not clickable/openable #14291

Activity

1. AmethystLiang

   added

   P0

   on Aug 13, 2026
2. nwparker

   removed

   P0

   on Aug 19, 2026
3. ishibe-ai commented on Aug 25, 2026

   

   ishibe-ai

   on Aug 25, 2026

   Last edited by ishibe-ai

   More actions

   Reproduces on macOS/zsh as well — this is not PowerShell-specific.

   Orca 1.4.187 (running session) / 1.4.188 (installed), macOS 15.5 (Darwin 25.5.0),
   TERM=xterm-256color, zsh, agent pane running Claude Code.

   Slightly different symptom on this side: a wrapped URL is not clickable at all,
   rather than opening a truncated one. Same trigger though — the wrap.

   Confirmed by shrinking the font size until the identical URL fit on one line:
   it became clickable immediately, with no change to the output itself.

   The wrap only breaks one of Orca's two rendering paths

   The same URL behaves differently depending on where it is printed:

   Rendered in	Wrapped across 2 lines	Clickable
   Agent response body (markdown)	yes	yes — rendered as a single <a>, underlined
   Terminal output (shell result)	yes	no — no underline, no hit target

   Identical URL, identical length, identical wrap. Only the surface differs. So the
   markdown renderer already joins wrapped lines correctly; it appears to be the
   terminal buffer's linkifier that scans per visual row rather than per logical line.

   Length and character set are not the cause

   All of these were clickable while they fit on a single line in the terminal:

   Case	Length	Clickable
   file:///tmp/orca-test-a.html	33	yes
   file:///tmp/orca%20test%20b.html (percent-escaped spaces)	39	yes
   file:///tmp/%E6%97%A5%E6%9C%AC%E8%AA%9E.html (encoded Japanese)	44	yes
   file:///tmp/aaaaaaaaaa-...-qqqqqqqqqq.html (long ASCII, one line)	203	yes
   same style of path, wrapped to two lines	~250	no

   Worth noting this hits non-ASCII paths hardest: percent-encoding expands each
   character ninefold (経 becomes %E7%B5%8C), so those URLs wrap far sooner than
   their visible length suggests. On a Japanese directory tree, most file:// links
   in terminal output are effectively unusable.

   👍React with 👍1Reacted by Oliver Mannion
4. sec-ce commented on Aug 27, 2026

   

   sec-ce

   on Aug 27, 2026

   More actions

   I have the same issue described but it happens in both powershell and cmd. I find in cmd it works some of the time, then other times it stops. I haven't found an example of why yet.
5. mmarabel commented on Aug 31, 2026

   

   mmarabel

   on Aug 31, 2026

   Contributor

   More actions

   Reproduces in Pi's fullscreen TUI, so this is not PowerShell-specific.

   Environment:

   • Orca 1.4.188 on macOS
   • Pi session running in a remote-hosted workspace
   • Long OAuth authorization URL rendered by Pi as a Markdown link

   Repro:

   1. Have Pi print a Markdown link whose https://... target contains a long OAuth query string (response_type, client_id, code_challenge, redirect_uri, state, scope, etc.).
   2. Make the terminal narrow enough that Pi renders the parenthesized target across multiple rows.
   3. Hover or modifier-click the first URL row.

   Actual:

   • Only the first physical row is underlined/clickable.
   • Orca's hover target ends exactly where that row ends.
   • Opening it drops every continuation-row parameter, so the OAuth provider reports invalid/missing parameters.

   Expected:

   • Every rendered row should resolve to the same complete URL, and clicking any row should open the full target once.

   The continuation rows are aligned/indented by Pi rather than represented as a normal xterm soft wrap, which appears consistent with the logical-line reconstruction gap discussed here. This likely provides a useful non-PowerShell regression fixture for #14784: an indented multi-row authorization URL whose continuation begins in the middle of a query value, not at / or another URL delimiter.
6. OrcaWin

   added

   bugSomething isn't workingSomething isn't working

   os:Windows

   on Sep 19, 2026
7. OrcaWin

   added the

   Bug

   issue type on Sep 19, 2026
8. szsip239 commented on Oct 2, 2026

   

   szsip239

   on Oct 2, 2026

   More actions

   Additional reproducible case: CJK / parentheses file paths hard-wrapped by a TUI

   Reproduced on Orca 1.4.218, macOS, in a Codex CLI 0.159.3 terminal pane (not Native Chat). An assistant response contained two valid file:// Markdown targets. Codex displayed them as label (decoded local path): the .md target fit on one physical row and clicking it produced Orca's file-actions popover; the longer HTML target crossed two rows and clicking either segment produced no file-actions popover. Both files existed, and the rendered paths had no Markdown backslash escapes.

   We isolated the link-detection failure without running Codex: replayed the same text into the real @xterm/headless@6.1.0-beta.302 buffer and passed its rows through the unmodified v1.4.218 buildHardWrappedPathLogicalLineCandidates / buildWrappedLogicalLine, extractTerminalFileLinkCandidates, resolveTerminalFileLink, and range mapping. Filesystem existence was checked against real fixture files.

   Same existing HTML target	Complete target recognized
   Explicit newline + indentation inside the path; both rows isWrapped: false	No
   Complete path on one row	Yes
   Same paragraph soft-wrapped by xterm; continuation isWrapped: true	Yes

   The following minimal matrix also reproduces, without any agent process:

   Path characters	Single row	Explicit hard wrap after final-
   ASCII control	Yes	Yes
   CJK directory	Yes	No
   CJK filename	Yes	No
   Filename parentheses	Yes	No

   Small standalone fixture (macOS / Python 3)

   Run in an Orca terminal wide enough for each single control to fit on one row. Click the paths on both halves of each hard case. The script creates only temporary fixture files under /tmp; it deliberately keeps them present for the click/existence check. It runs no Codex/Claude process.

   from pathlib import Path
   from tempfile import mkdtemp
   
   root = Path(mkdtemp(prefix="orca-file-link-", dir="/tmp"))
   cases = [
       ("ASCII control", "ascii", "final-article.html"),
       ("CJK directory", "产物", "final-article.html"),
       ("CJK filename", "ascii", "final-排版.html"),
       ("Parentheses filename", "ascii", "final-(olive-journal).html"),
   ]
   for name, directory, filename in cases:
       target = root / directory / filename
       target.parent.mkdir(parents=True, exist_ok=True)
       target.write_text("fixture\n", encoding="utf-8")
       before, after = str(target).split("final-", 1)
       print(f"{name}: single ({target})")
       print(f"{name}: hard ({before}final-\n  {after})\n")

   The printed fixture text has also been replayed through the real xterm buffer and the pinned Orca detector: all four single-row controls pass; only the ASCII hard-wrap control passes. The packaged-app click observation above is from the original conversation; the matrix is parser/buffer replay evidence, not a claim of additional packaged-app GUI coverage on every row or OS.

   Location and relationship to existing work

   The ordinary local-path detector already accepts Unicode letters and filename parentheses. In contrast, hard-wrapped-terminal-path-fragments.ts at v1.4.218 still uses the ASCII-only HARD_WRAPPED_PATH_FRAGMENT_PATTERN, and its prefix/suffix/start predicates reject these characters. Its implementation and wrapped-terminal-link-ranges.ts were byte-identical in current main when checked on 2026-10-02; this is not a claim that the full current-main app or every open PR was live-tested.

   Related work:

   • Fix hard-wrapped terminal file links #8100 (merged): adds boundary reconstruction for hard-wrapped file links, but the remaining character-set/boundary gap above survives in 1.4.218.
   • [Bug]: Terminal link regex still cuts CJK paths at Unicode punctuation such as KATAKANA MIDDLE DOT (U+30FB) after #13399 #23019 / fix(terminal): keep CJK name punctuation inside terminal file links #23061 and fix(file-links): detect non-Latin paths and trim prose glued around them #17827: non-Latin / CJK path detection; their changed-file lists do not include this hard-wrap fragment module.
   • fix(terminal): link paths typed after a prompt cwd and probe glued hard-wrap guesses before opening #23221: probes ambiguous glued candidates before opening. This case fails earlier: the complete CJK/parentheses target never becomes a candidate, so existence probing alone cannot recover it.

   This is an Orca file-link reconstruction gap triggered by TUI hard wrapping, not a malformed Codex-generated path, an HTML-opening limitation, or a clipboard-escape reproduction. It is related to this issue, but distinct from the HTTP/OAuth continuation examples already discussed here. A regression should assert the same complete target and correct xterm cell range from either physical row, while retaining ASCII controls and not absorbing neighboring links/prose. This is additional pre-existing coverage to consider, not an assertion that any of the open PRs introduced the bug.
9. szsip239 commented on Oct 3, 2026

   

   szsip239

   on Oct 3, 2026

   More actions

   Follow-up: both local-file findings are now covered by #24960:

   1. Existing Unicode bare filenames printed as label (精读-阻塞清单.md) are rejected even on a single row. Prefixing ./ is a parser control, not a file-renaming requirement.
   2. The original mixed-label, parenthesized hard-wrapped target still fails against fix(terminal): link Unicode hard-wrapped file paths #24929 alone. Its Unicode fragment work is useful and credited; the remaining start predicate/display-wrapper boundary needs coverage too.

   The original real-xterm replay now recovers the complete HTML target under hard wrapping, while single-row and soft-wrap controls remain passing. The new regression uses ANSI-colored output, real temporary files and Orca's provider/action route without starting Codex or another agent; editor/store/IPC outputs are mocked.

   Local result: 254 tests / 15 files, renderer typecheck and changed-code quality pass. The PR includes both fixes, cell-range checks, Windows/tilde path fixtures, and closed-wrapper/unrelated-next-row guards. It does not change HTTP/OAuth URL detection, Codex output or opening permissions. No packaged-app after screenshot, live Windows/Linux/SSH-host verification, merge or deployment is claimed.
10. innocarpe

    added a commit that references this issue on Oct 29, 2026

    fix(terminal): join wrapped PowerShell URLs before opening

    ...

    1a50e5f