Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@apps/backend/src/lib/local-emulator.ts`:
- Around line 78-82: The current try/catch converts all errors from
parseStackConfigFileContent into a BadRequest StatusError; change this to only
catch the parser's expected validation error (e.g., the specific class thrown by
parseStackConfigFileContent such as StackConfigValidationError or
ConfigParseError) and map that to new StatusError(StatusError.BadRequest,
message), while rethrowing any other error unchanged so internal failures
bubble. Locate the parseStackConfigFileContent call and its error type, import
that specific error class, and replace the broad catch with a conditional check
(instanceof the parser error) that converts to BadRequest otherwise throw the
original error.

In `@apps/backend/src/lib/projects.tsx`:
- Around line 325-326: The branch currently skips writing environment overrides
for development creates, which silently drops any provided options.data.config;
update the logic in the create flow (the isCreatingDevelopmentEnvironment check)
to fail fast when a caller supplies a non-empty options.data.config during a
development-environment create: detect options.type === "create" &&
options.data.is_development_environment === true and if options.data.config is
present/non-empty, throw or return a validation error instead of continuing,
referencing the same variables used now (isCreatingDevelopmentEnvironment,
options.data.config, configOverrideOverride) so callers are rejected up-front
rather than having their config silently discarded.

In `@apps/dashboard/next.config.mjs`:
- Around line 59-60: The build switch uses an unprefixed env var
process.env.NEXT_CONFIG_DISABLE_TYPESCRIPT in the typescript.ignoreBuildErrors
setting; rename this to a STACK-prefixed variable (e.g.,
process.env.STACK_DISABLE_TYPESCRIPT) everywhere it’s referenced and update any
documentation/CI that sets NEXT_CONFIG_DISABLE_TYPESCRIPT to set
STACK_DISABLE_TYPESCRIPT instead so Turborepo/turbo caches see the change;
ensure the check still compares to the same "true" string and update any
examples or env schemas so the new STACK_ variable is the canonical one.

In `@apps/dashboard/src/app/api/development-environment/health/route.ts`:
- Around line 39-55: localEmulatorIsHealthy currently calls fetch() with no
timeout which can hang; update the function to use an AbortController with a
short timeout (e.g., 1–3s) and pass controller.signal into fetch, set a timer to
call controller.abort() after the timeout, and clear the timer on success or
failure; ensure the catch block treats abort/errors the same (return false).
Reference the localEmulatorIsHealthy function and the fetch call so you add the
AbortController, timer, and signal handling around that fetch.

In `@apps/dashboard/src/app/api/remote-development-environment/auth/route.ts`:
- Around line 56-69: The GET handler returns a bearer token but doesn't set
cache headers; update the response created by NextResponse.json in the GET
function to include a Cache-Control of "private, no-store" (e.g., either pass
headers into NextResponse.json or call response.headers.set('Cache-Control',
'private, no-store')) before calling deleteInternalProjectAuthCookies and
returning the response so browsers and intermediaries will not persist or replay
the token payload.
- Around line 21-33: The current
assertRemoteDevelopmentEnvironmentBrowserRequest relies solely on
caller-controlled headers (Host/Origin/sec-fetch-site) which can be spoofed;
update the function assertRemoteDevelopmentEnvironmentBrowserRequest to enforce
locality using an unforgeable transport-level indicator (e.g., the connection's
remote address / socket peer address) rather than only header checks: add a
check that the request's remote IP (socket.remoteAddress, req.ip or the
platform-specific request connection property) is a loopback address and reject
requests otherwise, and keep the existing
requestHostIsLoopback/originIsAllowed/sec-fetch-site header checks as secondary
defenses; ensure this new remote-address-based check is performed before
returning any success and that any forwarding headers are not trusted.

In
`@apps/dashboard/src/app/api/remote-development-environment/config/apply-update/route.ts`:
- Around line 14-30: The code calls await req.json() which can throw on
malformed JSON and currently results in a 500; wrap the call in a try/catch
around the req.json() invocation (before the existing validation of body) to
catch JSON parse errors and return a NextResponse.json(...) with a 400 status
and an "invalid JSON" or "malformed request body" message, while re-throwing any
non-JSON parse errors; ensure you keep using the same body variable for the
subsequent validation block so the rest of the checks
(session_id/project_id/config_update/wait_for_sync) remain unchanged.

In `@apps/dashboard/src/app/api/remote-development-environment/sessions/route.ts`:
- Around line 18-27: Wrap the await req.json() call in a try/catch so JSON parse
errors return a 400 instead of throwing a 500; catch the error around obtaining
"body" in the route handler, return NextResponse.json({ error: "Malformed JSON"
}, { status: 400 }) (or include error.message if desired), and then continue
with the existing checks for typeof body.api_base_url/config_path and
isAllowedApiBaseUrl to preserve current validation flow.

In `@apps/dashboard/src/app/layout-client.tsx`:
- Around line 48-79: The polling can overlap and stale responses can overwrite
newer state; modify refreshDevEnvironmentHealth/subscribeDevEnvironmentHealth to
prevent this by either (A) tracking a single in-flight request flag (e.g.,
devEnvironmentHealthInFlight) and skipping/deferring new probes while true, or
(B) use an incrementing sequence token (e.g., devEnvironmentHealthSeq) captured
by each invocation and only apply state updates if the token matches the latest
value; adjust runAsynchronouslyWithAlert calls and the interval callback to
respect this guard and keep
devEnvironmentHealthTimer/devEnvironmentHealthSubscribers logic unchanged
otherwise.

In `@apps/dashboard/src/stack/client.tsx`:
- Around line 26-31: The analytics replay settings re-enable session recording;
change the replays config so session recording stays off and inputs remain
masked by setting replays.enabled = false (rather than using
isPreview/isRemoteDevelopmentEnvironment logic) and replays.maskAllInputs =
true; update the analytics -> replays block (symbols: analytics, replays,
maskAllInputs, enabled, isPreview, isRemoteDevelopmentEnvironment) accordingly
so dashboard flows always have sessionRecording disabled and input masking
enabled.

In `@packages/stack-cli/src/commands/dev.ts`:
- Around line 410-413: The heartbeat currently bails on any non-ok HTTP response
(response.ok false) and leaves the child process running; change the non-ok
branch to perform the same recovery as network errors: log the status and body
(using logDev and await response.text()), then terminate/cleanup the child
process and invoke the existing re-register/restart flow used for network
failures (reuse the same error handler or call the same cleanup + restart
routine) so the command will restart and re-register the session instead of
silently stopping the heartbeat.
- Around line 432-482: Add end-to-end tests that exercise the new CLI flow
exposed by registerDevCommand: write tests that invoke the CLI entrypoint (using
the same startDashboardIfNeeded/test emulator harness used elsewhere) with
--config-file and a simple child command so the code path through
createRemoteDevelopmentEnvironmentSession, heartbeatUntilStopped,
runChildProcess, maybeOpenOnboardingPage, and closeSession executes; assert the
session was registered (createRemoteDevelopmentEnvironmentSession
called/returned session_id), verify heartbeats were observed by the emulator
while the child process runs, then ensure closeSession is called when the child
exits. Also add a separate test that simulates a restart/re-register scenario
(stop the child, restart the CLI or simulate retry) and assert a new session
registration occurs and the old session is closed. Use the existing emulator
test helpers and spies/mocks around createRemoteDevelopmentEnvironmentSession,
heartbeatUntilStopped (or the emulator endpoint that receives heartbeats), and
closeSession to validate register → heartbeat → close and re-register behavior.
- Around line 219-222: The isDashboardReachable function currently probes
`${url}/health`; update it to request the new health path
`/api/development-environment/health` instead (i.e., fetch
`${url}/api/development-environment/health`) so the dashboard readiness check
hits the actual endpoint added in this changeset; ensure the function name
isDashboardReachable remains the same and that the returned boolean behavior
(return response.ok) is preserved.
- Around line 162-171: The replaceSentinels function currently leaves unresolved
sentinel strings in the output when an expected runtime env var is missing;
update replaceSentinels (which uses SENTINEL_REGEX, USE_INLINE_ENV_VARS_SENTINEL
and SENTINEL_PREFIX) to throw an Error when a sentinel begins with
SENTINEL_PREFIX but env[varName] is undefined (extract varName via
sentinel.slice(SENTINEL_PREFIX.length)) instead of returning the original
sentinel, while still returning "true" for USE_INLINE_ENV_VARS_SENTINEL and
returning non-sentinel values unchanged.

In `@packages/stack-cli/src/lib/dev-env-state.ts`:
- Around line 37-41: The POSIX permission enforcement using statSync(...) and
chmodSync(...) can throw on Windows because ACLs don’t reflect POSIX mode bits;
update the block around statSync(path) / chmodSync(path) in dev-env-state.ts to
run only on non-Windows platforms (e.g. guard with process.platform !== 'win32'
or os.platform() check) so the chmod retry and subsequent throw are skipped on
Windows, leaving existing logic unchanged for POSIX systems; reference the
existing statSync, chmodSync and path identifiers when applying the guard.

In `@packages/template/src/lib/stack-app/apps/implementations/session-replay.ts`:
- Around line 35-40: The serializer/deserializer that rebuilds
replays.blockClass is dropping top-level AnalyticsOptions fields (notably
AnalyticsOptions.enabled) which can silently re-enable analytics; update the
code that reconstructs the options for replays.blockClass to preserve/propagate
AnalyticsOptions.enabled (and any other top-level fields) from the original
object instead of only using nested properties—e.g., when transforming in the
replays.blockClass handling logic, merge/spread the original AnalyticsOptions
(or explicitly read and copy enabled) into the rebuilt object so both
serialization and deserialization roundtrips keep enabled intact.

---

Minor comments:
In `@apps/backend/prisma/seed.ts`:
- Around line 431-433: The oauth_providers mapping is using an unnecessary and
unsafe cast "id as any" even though oauthProviderIds is a string[] and the
schema (oauthIdSchema) expects a string; remove the cast so the mapping uses
"id" directly (i.e., change id: id as any -> id) in the oauth_providers.map over
oauthProviderIds and remove the identical "id as any" cast found earlier in the
file (the other occurrence where an oauthProviderIds element is mapped) so
typechecking works correctly.

In `@apps/dashboard/package.json`:
- Line 15: The build script "build:rde-standalone" sets
NEXT_CONFIG_DISABLE_TYPESCRIPT=true which allows skipping TypeScript checks;
update the script or repository docs to prevent accidental bypass by either: (a)
prefixing the script to run pnpm run typecheck (or require explicit typecheck)
before invoking the build, or (b) add a clear comment/README entry near the
"build:rde-standalone" script documenting that this script disables TypeScript
checks and must only be used when TypeScript validation is enforced separately
(e.g., CI), referencing the "build:rde-standalone" script name and the
NEXT_CONFIG_DISABLE_TYPESCRIPT flag so maintainers can find and review the
change.

In
`@apps/dashboard/src/app/`(main)/(protected)/(outside-dashboard)/projects/page-client.tsx:
- Around line 90-93: Replace the direct useUser(...) call and inline null throw
with the existing helper useDashboardInternalUser(): import
useDashboardInternalUser and call it instead of useUser(...) so the page reuses
the shared logic (including the same "anonymous-if-exists[deprecated]" and
projectIdMustMatch: "internal" behavior); if the auth gate does not guarantee a
user, handle the null/undefined return from useDashboardInternalUser()
gracefully (or document the invariant) rather than throwing with throwErr.

In `@apps/dashboard/src/instrumentation.ts`:
- Around line 8-9: The startup guard in instrumentation.ts mixes raw string
comparison and getEnvBoolean for the
NEXT_PUBLIC_STACK_IS_REMOTE_DEVELOPMENT_ENVIRONMENT flag; replace the string
equality check in the if condition with the same boolean parser (use
getEnvBoolean("NEXT_PUBLIC_STACK_IS_REMOTE_DEVELOPMENT_ENVIRONMENT", false)) so
both checks use a single env-boolean parser and consistently determine remote
development environment when calling getNextRuntime() and the RDE flag.

In `@packages/stack-cli/src/commands/emulator.ts`:
- Around line 368-373: The catch block around runEmulator("stop") should only
handle expected CLI errors; change the generic catch to check if the thrown
error is an instance of CliError (e.g., if (e instanceof CliError) { write
message } ), and rethrow any other error so unexpected faults fail loudly; keep
the existing process.stderr.write call for the CliError case and ensure any
non-CliError is thrown again (or passed up) instead of being swallowed.

---

Nitpick comments:
In `@apps/backend/src/lib/local-emulator.ts`:
- Line 19: The writeShowOnboardingConfigToFile function is still serializing the
literal "show-onboarding" instead of using the shared sentinel constant, which
breaks round-trip if that sentinel changes; update
writeShowOnboardingConfigToFile to use LOCAL_EMULATOR_SHOW_ONBOARDING_VALUE (the
exported constant from this file) when writing the config key so
readConfigValueFromFile and writers use the same single source of truth.