[Desktop] Open in Finder fails for URL-encoded local paths (Chinese filenames)

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #11102

Powered by Codex Action

I am seeing what looks like the same non-ASCII local-path encoding problem in the Windows Codex desktop app as well.

Related active Windows issue: #14079.

Additional detail from the Windows side:

• this is not just a long-path problem
• it reproduces when any clickable local-path segment is non-ASCII (for example Chinese directory names or Chinese filenames)
• once a non-ASCII segment appears, the local chat link target becomes percent-encoded (%...) and does not open correctly

So this looks like a cross-platform member of the same bug family: local file link targets are being passed around in encoded form without being converted back into a usable filesystem path before the open action.

For cross-reference, this non-ASCII local-path encoding issue also appears related to:

• #14079: currently active Windows desktop local-link parsing / normalization bug
• #13548: older Windows desktop symptom where local links resolved to invalid c:\\C:\\... paths

From current repros, #14079 looks like the broader active tracker, while this issue captures the non-ASCII / percent-encoding side of the same local-file-link bug family.

<img width="631" height="276" alt="Image" src="https://github.com/user-attachments/assets/6b7e5747-778b-4664-a022-aca438be6bad" />

And it will leave URL-encoded folders on disk.

I should mention that this happens with spaces as well. So for any project that happens to have a space anywhere, any links that codex generates to particular files are unusable because they contain %20 encodings.

Confirming this on macOS as well.

Environment:

• Codex Desktop 26.325.31654
• Build 1272
• macOS

What I reproduced:

• Right-click a local file link whose path contains Chinese characters.
• Open in Finder does nothing useful.
• Copy path returns a percent-encoded filesystem path instead of the real local path.

Concrete example from a failing item:

/Users/<user>/CodexProjectRoots/%E6%8A%80%E8%83%BD%E4%B8%8E%E7%B3%BB%E7%BB%9F%E9%85%8D%E7%BD%AE/output/cta-songhu-chatgpt-source-pack-20260331

The actual path on disk is the decoded one:

/Users/<user>/CodexProjectRoots/技能与系统配置/output/cta-songhu-chatgpt-source-pack-20260331

Local verification:

• encoded copied path: does not exist
• decoded path: exists
• open -R <encoded path>: fails with "The file ... does not exist."
• open -R <decoded path>: succeeds

So on macOS this is not a Finder problem. The failing condition is that the app is handing Finder a URL-encoded local filesystem path instead of a decoded path.

Impact:

• Open in Finder breaks for affected links
• Copy path also produces a path that is not directly usable in Finder or the shell

Adding another macOS reproduction with a Japanese filename.

Environment:

• Codex App / CLI: I can provide the exact About dialog version if needed.
• Platform: macOS, Japanese local path / filename.

What I’m seeing:

• The visible chat label is decoded and readable, e.g. 配布版_強化版.pdf.
• The hover / clickable target is still percent-encoded, e.g. path segments like %E9%85%8D....
• Clicking the link does not open the file, while English-only filenames open correctly.

Expected:
Codex should decode percent-encoded local file paths before handing them to the open/copy/Finder path handling layer, so Japanese filenames work the same way as English filenames.

Screenshot:

!Japanese filename local file link hover shows percent-encoded target

Additional current macOS reproduction on a newer Codex Desktop build.

Environment

• Codex Desktop: 26.616.51431
• CFBundleVersion: 4212
• macOS: 26.5.1 (25F80)
• Architecture: Apple Silicon / arm64

What still reproduces

This is still reproducible for local paths containing either:

• non-ASCII path segments, e.g. Chinese directory names
• spaces in directory or file names

User-visible regression:

• In Codex Desktop, opening a local file/folder via the Finder/open-folder action fails when the path contains Chinese characters or spaces.
• The same workflow previously worked.
• The failure mode matches the earlier reports here: the app appears to pass a percent-encoded path such as %E4%B8%AD... / %20 to the filesystem/Finder layer instead of decoding it back to the real local path first.

Minimal local verification

Created a local test file under a path containing both Chinese characters and spaces:

~/.../work/中文 路径测试/space folder/test file.md

The decoded filesystem path exists:

decoded_exists=True

The URL-encoded filesystem-looking path does not exist:

.../work/%E4%B8%AD%E6%96%87%20%E8%B7%AF%E5%BE%84%E6%B5%8B%E8%AF%95/space%20folder/test%20file.md
encoded_exists=False

Expected behavior

Before invoking Finder / "Open in Finder" / open-folder handling, Codex Desktop should convert URL/path targets to native filesystem paths exactly once:

• decode %E4... segments to Unicode path segments
• decode %20 to spaces
• avoid double-decoding already-native filesystem paths
• then call the platform open/Finder API with the decoded native path

This should apply to both file and folder links.

Follow-up with a macOS control test that isolates this from Finder/macOS itself.

Using the same test file under a path containing both Chinese characters and spaces:

~/.../work/中文 路径测试/space folder/test file.md

I tested three inputs to macOS open -R:

DECODED_OPEN
decoded_status:0

ENCODED_OPEN
The file .../work/%E4%B8%AD%E6%96%87%20%E8%B7%AF%E5%BE%84%E6%B5%8B%E8%AF%95/space%20folder/test%20file.md does not exist.
encoded_status:1

FILE_URL_OPEN
file_url_status:0

So macOS/Finder can open:

• the native decoded filesystem path
• a proper file:// URL containing percent encoding

It fails only when the percent-encoded URL path is passed as a native filesystem path.

That points to Codex Desktop needing to normalize at the boundary:

• for file://... links, convert with URL/file-URL semantics into a native path before calling Finder
• for already-native local paths, avoid handing %20 / %E4... strings to open -R or Electron's Finder/open-path equivalent
• invoke the open operation with argv/native path values, not a shell-joined string

Additional directory-specific finding.

The previous control test covered file reveal behavior. Directory opening has a slightly different failure mode.

In a user-facing terminal repro, direct directory open can fail when the directory path ends with a trailing slash:

open "/Users/<user>/Documents/Codex/2026-06-19/zhe/work/中文 路径测试/space folder/"

Observed behavior:

• open exits with status 0
• Finder opens/returns to the home folder (/Users/<user>/) instead of the target directory
• This matches the user-visible screenshot: the command returns without an error, but Finder is not at the requested directory

The same user reports that removing the trailing slash from the same directory path makes it open correctly in their normal terminal.

From the Codex-controlled diagnostic shell, I could reproduce the "returns to home" behavior for the directory-open path. The exact trailing-slash/no-trailing-slash split appears environment-sensitive, but it still points at a missing path-normalization step before calling Finder/LaunchServices.

Controls:

• Direct open works for a Chinese + space directory under /private/tmp.
• Direct open works for top-level locations like /Applications, ~/Downloads, and ~/Desktop.
• Direct open fails for multiple ~/Documents/* subdirectories by returning to home.
• open -R works for the same deep target directory when revealing it:

open -R "/Users/<user>/Documents/Codex/2026-06-19/zhe/work/中文 路径测试/space folder"
=> Finder target becomes:
/Users/<user>/Documents/Codex/2026-06-19/zhe/work/中文 路径测试/space folder/

So there are two related but distinct path handling issues:

1. Percent-encoded local paths must be decoded before any filesystem/Finder operation.
2. Directory paths should be normalized before opening, including removing a trailing slash where the platform API is sensitive to it.
3. For directories, using a reveal-style operation (open -R / Finder reveal / platform equivalent) may be more reliable than direct open <directory> in this protected ~/Documents subtree.

Suggested app-side behavior:

• If the target is a file: decode to a native path, then reveal/select it in Finder.
• If the target is a directory: decode to a native path, normalize it (path.normalize / strip trailing separator except filesystem root), then reveal/open it using Finder reveal semantics, not a shell-opened URL-encoded path.
• Avoid treating a percent-encoded path string as a native filesystem path.