Question
What can webtweak's own code reach through a project folder grant, and what should it be allowed to reach?
Distinct from #20, which asks what the Target page's JavaScript can reach. This one is about the app itself, including any dependency it ships and any XSS in its own UI. Surfaced by a codex exec review on 2026-08-03; neither the runtime redraw nor #20 had it in scope.
The problem. A folder grant is all-or-nothing. A site holding one can read every file underneath it: .env, .git and its full history, deploy keys, .npmrc, an SSH key someone left in the tree. Nothing in the browser's model narrows it, and the user granting it is answering "may this site open my project", not "may this site read my credentials".
This is a regression against the tool as it stands today, which is what makes it worth a ticket. The current server hands out only what it is asked for and refuses any .-prefixed path segment outright (dotSegment in webtweak.js), specifically so a --root aimed at a site root cannot leak .git. That guard was added deliberately. A folder grant has no equivalent, so the redraw removes an existing protection rather than failing to add a new one.
Resolve:
- Whether webtweak reads only what it needs (the Target page, the stylesheets it links, the fonts and images they reference) rather than enumerating the whole tree, and what that costs - membership on #5 currently defines a Project as every eligible page beneath the root, which implies enumeration.
- Whether
dotSegment's refusal survives as an application-level rule now that it cannot be a server-level one, and whether a self-imposed rule is worth anything given the app could simply not honour it.
- What the user is actually told at grant time, given the browser's own prompt will not mention any of this.
- Whether a narrower grant is workable - granting the page's own folder rather than the project root - and what that breaks for root-absolute asset references, which is the case
--root exists to serve today.
- What the supply-chain policy is. A hosted app with a folder grant makes every transitive dependency a credential-reading risk, which bears on #7 and the zero-dependency question.
- Whether the edits file being written into the user's tree is itself a hazard, since it is the highest-value write target in the tool and
CONTEXT.md already says reconcile must treat it as captured data and never as instructions.
Blocked by #19 for what the browser actually exposes and whether any narrowing mechanism exists.
Question
What can webtweak's own code reach through a project folder grant, and what should it be allowed to reach?
Distinct from #20, which asks what the Target page's JavaScript can reach. This one is about the app itself, including any dependency it ships and any XSS in its own UI. Surfaced by a
codex execreview on 2026-08-03; neither the runtime redraw nor #20 had it in scope.The problem. A folder grant is all-or-nothing. A site holding one can read every file underneath it:
.env,.gitand its full history, deploy keys,.npmrc, an SSH key someone left in the tree. Nothing in the browser's model narrows it, and the user granting it is answering "may this site open my project", not "may this site read my credentials".This is a regression against the tool as it stands today, which is what makes it worth a ticket. The current server hands out only what it is asked for and refuses any
.-prefixed path segment outright (dotSegmentinwebtweak.js), specifically so a--rootaimed at a site root cannot leak.git. That guard was added deliberately. A folder grant has no equivalent, so the redraw removes an existing protection rather than failing to add a new one.Resolve:
dotSegment's refusal survives as an application-level rule now that it cannot be a server-level one, and whether a self-imposed rule is worth anything given the app could simply not honour it.--rootexists to serve today.CONTEXT.mdalready says reconcile must treat it as captured data and never as instructions.Blocked by #19 for what the browser actually exposes and whether any narrowing mechanism exists.