Repository navigation
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/server
Steps to reproduce
- In a project, create:
with
c.png site/index.html site/style.css site/a.png site/img/b.pngsite/index.htmlreferencingstyle.css,./a.png,img/b.pngand../c.png. - From a thread of that project, open
site/index.htmlin the file preview (e.g. by clicking a link to its absolute path). - Copy the same folder outside the thread's project and open that
index.htmlthe same way.
Expected behavior
Relative resources load as they do when the file is opened in a browser via file://, including references that climb with ../ while staying inside the project (e.g. <img src="../../../assets/logo/logo.png"> from proposals/v2/opus/index.html).
Actual behavior
- Inside the project:
style.css,./a.pngandimg/b.pngload;../c.pngdoes not. - Outside the project: nothing relative loads, not even
./a.pngor the CSS.
Cause, as far as I can tell from apps/server/src/assets/AssetAccess.ts:
finalizeWorkspaceFileAssetgives workspace HTML aworkspace-filegrant scoped topath.dirname(file), andissueAssetUrlbuilds/api/assets/<token>/<basename>. The browser normalizes../c.pngagainst that URL to/api/assets/c.pngbefore sending the request, so the token segment is gone and the request 404s. The..check inresolveAssetnever even gets to run.- HTML outside the thread's project goes through
media-file(apps/web/src/components/files/filePreviewMode.ts,workspaceAssetResource), which is an exact-file grant, so no relative resource resolves.
A possible fix for the first case: root the HTML grant at the workspace and put the page's workspace-relative path in the URL (/api/assets/<token>/site/index.html), so ../ references resolve under the token. The existing dotfile, extension allowlist and root-containment checks would still apply. The trade-off is that an HTML page could load allowlisted resources from the whole workspace instead of only its own folder. I have this change with a regression test on a local branch and can open a PR if this direction is acceptable. It touches the same code as #18239.
The outside-the-project case needs a decision about which folder to grant without a project root, so I left it out.
Impact
Minor bug or occasional failure
Version or commit
main at 4c9c7d0
Environment
macOS desktop app
Activity
jkramer5103 commentedon Oct 31, 2026
[codex] Following the closure of #26919 for missing prior scope approval, could a maintainer confirm the intended authorization boundary for this reported failure before any further implementation work?
The proposed behavior is to preserve the HTML entry’s workspace-relative path beneath its signed token and allow dependencies that resolve elsewhere within the same workspace, subject to the existing extension allowlist, hidden-path restrictions, and canonical containment/symlink checks. This broadens the grant beyond the entry directory. For an explicitly selected hidden-directory entry such as
.output/public/index.html, the proposal also permits sibling assets beneath its exact signed hidden-directory prefix, while rejecting unrelated hidden paths. Files outside the workspace retain exact-file grants.Is that workspace-wide dependency scope, including the selected hidden-directory behavior, acceptable, or should dependency access retain a narrower boundary? The parent-relative resource failure documented above remains reproducible independently of accepting this solution. I will leave #26919 closed and wait for explicit maintainer direction before requesting reconsideration.