[7ttp]

TL;DR

brings the apps/cli-e2e replay server under the effect lint, so the allow list covers the whole

whats introduced?

• the server runs on FileSystem, HttpClient and typed errors with Bun.serve as its only edge, and the global setup owns it through a scope
• the docker relay uses the node:http client from @effect/platform-node, because bun's fetch sorts response headers and recorded fixtures keep them in arrival order
• replay responses and recorded fixture files stay byte for byte the same

ps: in record mode the docker relay can send a response chunked where it used to send content-length, with the same body bytes, and a failed relay logs its own error instead of the raw socket error

ref

• closes: CLI-2880

[github-actions]

🤖 AI Review

Both independent reviews completed. Claude reported three findings; Codex reported none. Two findings are refuted by the configured runtime and the previous error-handling path. The enqueue race remains uncertain without Effect runtime validation; no blocking defect was confirmed.

Findings

Severity	Location	Category	Sources	Claim
⚪ NIT	apps/cli-e2e/src/server/replay-server.ts:879	error-handling	claude	After an idle timeout errors the downstream controller, the reader could enqueue another chunk before scope cleanup interrupts it, producing a TypeError.

Refuted findings (kept for transparency, not posted as review comments)

• apps/cli-e2e/src/server/replay-server.ts:235 (robustness): Docker routing relies on Bun honoring socketPath in Agent options and could misroute to localhost:80 on another Bun version.
  Refuted: The repository pins Bun 1.4.4. A native node:http probe under that exact runtime, using these Agent options, attempted the supplied Unix socket path rather than localhost:80. The finding identifies a dependency on runtime behavior, but its failure scenario requires an unsupported or hypothetical future runtime; it does not establish a defect on the configured runtime.
• apps/cli-e2e/src/server/replay-server.ts:803 (error-handling): Using the generic aborted error for idle timeout removes the descriptive timeout message previously shown in the Docker body-capture log.
  Refuted: The old descriptive error was passed to request.destroy, but the body-capture log consumed the separate response error. A transport-only reproduction under pinned Bun 1.4.4 produced 'Docker socket idle for 60s' on the request and 'aborted' on the response. The old body-capture log therefore also received 'aborted'; the claimed diagnostic regression is not present.

Stats

Claude findings: 3 · Codex findings: 0 · Confirmed: 0 · Refuted: 2 · Uncertain: 1

---

Models: claude-opus-5-5 + gpt-6.1-sol · Trigger: auto · Workflow run

This review runs once per PR. A maintainer can request another with a /ai-review comment.

[github-actions]

CLI benchmark: no changes found

Commit 7a3ea87 against 7ttp/cli-2879-tests-coverage at 7301531 · 10 runs each · report only, never blocks merging

Command	Before	After	Change
supabase --version	235 ms	258 ms	no real change (+9%, within normal variation)
supabase --help	223 ms	217 ms	no real change
supabase init	234 ms	219 ms	no real change (-6%, within normal variation)
supabase migration new bench	195 ms	204 ms	no real change
supabase gen types --lang typescript --project-id replayfixtureprojref	205 ms	231 ms	no real change (+13%, within normal variation)
supabase projects list	213 ms	209 ms	no real change
supabase functions list --project-ref replayfixtureprojref	191 ms	206 ms	no real change (+7%, within normal variation)

API calls: unchanged for all 7 commands.

Binary size: 134.0 MB, unchanged.

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

Timing ranges

Command	Before range	After range	Change	Verdict
supabase --version	210-307 ms	218-338 ms	+22 ms (+9%)	within noise
supabase --help	202-303 ms	199-294 ms	-6 ms (-3%)	within noise
supabase init	178-286 ms	182-288 ms	-15 ms (-6%)	within noise
supabase migration new bench	180-301 ms	183-303 ms	+9 ms (+5%)	within noise
supabase gen types --lang typescript --project-id replayfixtureprojref	192-259 ms	187-263 ms	+26 ms (+13%)	within noise
supabase projects list	199-254 ms	199-289 ms	-4 ms (-2%)	within noise
supabase functions list --project-ref replayfixtureprojref	172-219 ms	171-225 ms	+14 ms (+7%)	within noise

API calls per command

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

Slowest phases

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

Comment /bench to run it again on the latest commit.

Workflow run

[Coly010]

LGTM, thanks!