diff --git a/scripts/cef/run-launch-cycle-proof.mjs b/scripts/cef/run-launch-cycle-proof.mjs
index 5cc494916..ae43f749e 100644
--- a/scripts/cef/run-launch-cycle-proof.mjs
+++ b/scripts/cef/run-launch-cycle-proof.mjs
@@ -54,7 +54,17 @@ const cyclesArg = cyclesArgIdx !== -1 ? process.argv[cyclesArgIdx + 1] : undefin
 const cycles = cyclesArgIdx === -1 ? 3 : Number(cyclesArg);
 
 // QNBS-v3: raised from 4000ms after two consecutive CI runs on identical code (byte-for-byte matching main, which had passed reliably before) showed the browser process alive but never reaching OnAfterCreated within the old window — runner-speed variance, not a code regression.
-const STARTUP_GRACE_MS = 10000;
+// QNBS-v3: raised again from 10000ms after the same "Cycle 1: no FFI boundary proof" symptom
+// recurred on a main push right after PR #400 added -g to worldscript_host — real, measured
+// evidence: the binary grew from 1.34MB to 6.33MB (target_compile_options in
+// apps/desktop-cef/CMakeLists.txt), a plausible contributor to slower first-launch I/O on a
+// loaded runner. Cycles 2/3 in runCycle always passed at the old window — the actual observed
+// failure only ever hit the cold first launch there. This constant is also read by
+// runCrashReportingProofCycle's own renderer-crash-detection timeout below (line ~278) — a
+// shared constant, not a runCycle-only one; that consumer's failure-detection window widens by
+// the same 5s as a side effect, which is fine (strictly more lenient, same CI-runner-speed
+// rationale applies), not a dedicated timeout since there's no evidence the two need to differ.
+const STARTUP_GRACE_MS = 15000;
 const SHUTDOWN_GRACE_MS = 6000;
 // QNBS-v3: extra buffer after the main process exits — a renderer/GPU subprocess can take a moment longer to actually be reaped than its parent (docs/cef/knowledge/subprocess-and-shutdown.md's own "not instantaneous" finding applies to the whole tree, not just the browser process).
 const ORPHAN_CHECK_GRACE_MS = 3000;