Finder links not working properly due to spaces in filename

What version of the Codex App are you using (From “About Codex” dialog)?

Version 26.409.20454 (1462)

What subscription do you have?

Pro

What platform is your computer?

MacOS 26.4 and 26.4 (and previous versions as well)

What issue are you seeing?

When Codex completes its output, it provides finder links to the files that were edited or output. Because the MacOS finder system allows spaces in its file names and in fact it is almost impossible to avoid using spaces because the filesystem itself is often based on [Username][space][Computer Model], e.g. "John Doe's MacBook Pro M5." Codex attempts to convert this into Unicode by substituting &20 for space. So the clickable link that is generated contains &20 in it and the finder is unable to locate that file when you click it. When you hover over it, you can see the unicode. Try pasting that unicode into the Finder "Go to Folder" dialogue and it does not function.

My workaround (very clunky and wastes tokens):

1. I've asked Codex to render the links without &20, just spaces.
2. While Codex is "thinking" clickable links (in blue) appear rendered correctly. Clicking on them jump to the actual finder location (the desired behavior).
3. However, once it finishes "thinking" the links revert bak to some sort of internal markup that is not clickable: [project-panel.tsx](/Users/John Doe's Computer/Library/CloudStorage/Dropbox/random project/Codex/Subfolder/Project Name/src/object/interact/components/project-panel.tsx).
4. The path is correct and if I copy and paste just that path into the Finder "Go to Folder" it goes directly to that folder.
5. If I copy and paste the full markup into Codex chat, the system renders a functional link (but requires me making an unnecessary query just so that the file is clickable in the thread). So Codex is able to render the finder link, but only in the user's chat, not in the Codex response.

What steps can reproduce the bug?

Any action that generates an output and changed files generates a non-functioning link due to the presence of spaces in filenames. These are converted to &20 which the MacOS finder does not understand. And any attempts to fix it generate instead, unclickable links in markup language.

What is the expected behavior?

No screenshot due to PII. But the expect behavior is a working, functional and clickable finder link generated without using Unicode. Clicking on the link takes you to the location in the Finder. When you have a number of different codex projects in different folders, it is important to easily be able to know which files have been output / edited and where they are located.

Additional information

Nope that's about it. Clickable finder paths should not include unicode. The link should appear rendered as a working, functional link (blue) and clicking it should take you to the correct location in the finder.