[7ttp]

TL;DR

stack start now serves auth email templates from content_path instead of refusing them

whats introduced?

the api listener serves each configured template at /email/<id>?token=<uuid>, and auth fetches it from the runtime url it already calls

the file is read on every fetch, so edits and atomic replacements show up without a restart

reads stay inside the project root like legacy, and the open file is checked against its resolved path, so a swapped link or folder is refused

why/how?

the stack refused every content_path template, so projects with a custom invite or magic link email could not start on it

flowchart LR
  A[auth] -- GET /email/invite with token --> L{{api listener}}
  L -- regular file inside the project --> T[supabase/templates/invite.html]
  L -. anything else .-> X[404]

Loading

ref:

• closes: CLI-2583 & CLI-2746

[github-actions]

CLI benchmark (Lightweight Commands): no changes found

Commit 142a55f against develop at 4cc97fa · 10 runs each · report only, never blocks merging

Command	Workload	Before	After	Change
supabase --version	version	224 ms	198 ms	no real change (-12%, within normal variation)
supabase --help	help	199 ms	200 ms	no real change
supabase init	init	197 ms	191 ms	no real change
supabase migration new bench	migration-new	184 ms	185 ms	no real change
supabase gen types --lang typescript --project-id replayfixtureprojref	gen-types	186 ms	186 ms	no real change
supabase projects list	projects-list	168 ms	167 ms	no real change
supabase functions list --project-ref replayfixtureprojref	functions-list	180 ms	177 ms	no real change

API calls: unchanged for all 7 commands.

Binary size: 134.8 MB, up 20.0 KB from 134.7 MB.

Details: timing ranges, API calls per command, slowest phases

Timing ranges

Command	Workload	Before range	After range	Change	Verdict
supabase --version	version	174-310 ms	171-270 ms	-26 ms (-12%)	within noise
supabase --help	help	187-220 ms	178-220 ms	+1 ms (+0%)	within noise
supabase init	init	189-245 ms	178-237 ms	-5 ms (-3%)	within noise
supabase migration new bench	migration-new	174-198 ms	172-190 ms	+1 ms (+1%)	within noise
supabase gen types --lang typescript --project-id replayfixtureprojref	gen-types	180-224 ms	180-202 ms	+0 ms (+0%)	within noise
supabase projects list	projects-list	165-171 ms	166-172 ms	0 ms (0%)	within noise
supabase functions list --project-ref replayfixtureprojref	functions-list	171-188 ms	171-187 ms	-3 ms (-1%)	within noise

API calls per command

Command	Workload	Before	After	Endpoint changes
supabase --version	version	0	0
supabase --help	help	0	0
supabase init	init	0	0
supabase migration new bench	migration-new	0	0
supabase gen types --lang typescript --project-id replayfixtureprojref	gen-types	2	2
supabase projects list	projects-list	1	1
supabase functions list --project-ref replayfixtureprojref	functions-list	2	2

Slowest phases

No command moved beyond noise, so there are no phase deltas.

Workflow run

Comment /bench to run the lightweight benchmark (this comment) again on the latest commit, or /bench full to also run the integration-heavy benchmark, which posts in its own comment.

Previous runs

• 840d425 · 2026-11-06 15:15 UTC · no changes found · run

[Coly010]

Approving so you're unblocked, but there's one thing I'd like to see checked before this lands for Windows users.

1. FileSystem.ts:143,155 - the Windows read opens with FILE_FLAG_OPEN_REPARSE_POINT and refuses anything with FILE_ATTRIBUTE_REPARSE_POINT set. I think that catches more than links: OneDrive placeholders and dedup files carry that attribute too. If a project lives in a OneDrive-synced folder (Documents/Desktop are often redirected there), stack start would pass the start check, then every /email/<id> fetch would 404 and Auth would quietly send its built-in template. The only hint is the "Not a regular file at this path" warning from the owner.

   I haven't confirmed this on a real placeholder, so it may well not bite, and it needs someone with a Windows box to check. As far as I can tell the GetFinalPathNameByHandleW === resolved comparison already catches a swapped link or junction, so the no-follow flag and the attribute refusal might not be adding containment. Opening normally, or only refusing name-surrogate tags, would avoid the false refusal. Unless I'm missing something about why it's needed?

Smaller, all happy to be told no:

2. FileSystem.ts:237 and :162-163 - no size cap on the read. A misconfigured content_path pointing at a big in-root file (a dump, a build artifact) gets loaded whole on every Auth fetch. Something like 1 MiB, refused after stat, would cover it on both POSIX and Windows.
3. FileSystem.ts:150,153,226 - on Windows a CreateFileW failure (sharing violation from an editor, access denied, path over MAX_PATH) all surfaces as "Not a regular file", which points people at the wrong cause. Carrying the Win32 error code for those would help.
4. FileSystem.ts:234 - the macOS check works because Bun resolves realpath("/dev/fd/N") to the real path (Node doesn't). It fails closed, so no security impact, but a one-line comment saying it depends on that would save someone a confusing 404 later.

Otherwise this looks good to me!