@youdie006/prodex 0.16.31 → 0.16.32

package/README.md

@@ -35,7 +35,7 @@ prodex ask --file src/auth.ts "Review this for security holes"
 
 `prodex ask` is the short form of `prodex pro browser ask`; the full form and every flag work identically. In an interactive terminal, `login` keeps watching the opened window and tells you exactly which manual step is still missing (log in, clear a check, open a chat) until it reports READY. If you skip `login` and the browser is not running, an interactive `ask` recovers on its own: it launches the dedicated browser, waits for your saved session to be READY, and retries the send once (disable with `--no-auto-login`; scripts opt in with `--auto-login`). While ChatGPT thinks, `prodex` prints progress to stderr (connecting, prompt sent, elapsed seconds while generating), so a multi-minute Pro answer never looks frozen.
 
-The answer prints to your terminal and is saved under `.bridge/` for later (`prodex pro latest` re-prints it). Add `--new-chat` to send into a fresh chat (recommended for repeated consults - long threads eventually confuse send detection). For a structured second-opinion debate between your coding agent and GPT Pro, `prodex pro debate-prompt --topic "..."` prints a ready-to-paste orchestration prompt. `prodex` drives the picker you can see and deliberately will not send into a window you cannot watch — but a dedicated Chrome window left non-minimized (even behind your editor) counts as watchable, so it sends quietly in the background without stealing focus. Just don't minimize it or switch that window to another tab. Pin per-repo defaults once - `prodex setup --model Pro --project "your-project"` - so every ask runs Pro (15-minute timeout) inside that project instead of whatever the ChatGPT UI last had selected; list exact sidebar project names with `prodex pro browser projects`. Pass `--file` more than once to attach several files, and `--busy-wait-ms 600000` to queue behind an in-flight response when several agents share the browser. See [First Pro Login](#first-pro-login) for the full flow, and the [FAQ](#faq) if a send stops.
+The answer prints to your terminal and is saved under `.bridge/` for later (`prodex pro latest` re-prints it). Add `--new-chat` to send into a fresh chat (recommended for repeated consults - long threads eventually confuse send detection). For a structured second-opinion debate between your coding agent and GPT Pro, `prodex pro debate-prompt --topic "..."` prints a ready-to-paste orchestration prompt. `prodex` drives the picker you can see and deliberately will not send into a window you cannot watch — but a dedicated Chrome window left non-minimized (even behind your editor) counts as watchable, so it sends quietly in the background without stealing focus. Just don't minimize it or switch that window to another tab. Pin per-repo defaults once - `prodex setup --model Pro --project "your-project"` - so every ask runs Pro (15-minute timeout) inside that project instead of whatever the ChatGPT UI last had selected; list exact sidebar project names with `prodex pro browser projects`. Pass `--file` more than once to attach several files. When the thread is still generating a previous answer (common right after a timed-out Pro send), the send automatically queues behind it up to the timeout budget; tune that with `--busy-wait-ms` (0 fails fast with a `response_in_progress` blocker). See [First Pro Login](#first-pro-login) for the full flow, and the [FAQ](#faq) if a send stops.
 
 ## Core Shape
 

package/dist/chatgpt-browser.js

@@ -1,5 +1,5 @@
 import { spawn, spawnSync } from "node:child_process";
-import { accessSync, constants, readFileSync, statSync } from "node:fs";
+import { accessSync, constants, statSync } from "node:fs";
 import { mkdir, readFile, writeFile } from "node:fs/promises";
 import path from "node:path";
 import os from "node:os";
@@ -298,9 +298,11 @@ export function chatGptBusyBlocker(generating) {
         return undefined;
     return {
         code: "response_in_progress",
-        message: "ChatGPT is still generating a previous response.",
+        message: "ChatGPT is still generating a previous response in this thread.",
         retryable: true,
-        next_step: "Wait for the visible response to finish, or stop it manually in the browser, then retry."
+        next_step: "Wait for it to finish and retry (pass --busy-wait-ms to queue behind it longer). " +
+            "If that in-flight answer is the one you need, fetch it once it settles: `prodex pro browser recover --target-url <thread-url>`. " +
+            "A new topic can go to a new chat instead."
     };
 }
 export function isLikelyChatGptSubmitButton(label, dataTestId) {
@@ -564,6 +566,18 @@ function chatGptPageMissingBlocker() {
         next_step: "Open https://chatgpt.com/ in the dedicated Chrome profile, or run `prodex pro browser login` to reopen it."
     };
 }
+// Pre-send gate over a settled page status. Order matters: while ChatGPT
+// streams a response the composer locks (hasComposer reads false), so a busy
+// thread must be diagnosed as response_in_progress BEFORE the composer
+// readiness assert - otherwise it is misreported as "missing a visible prompt
+// composer" (measured live: continue-by-default consults landing on a thread
+// still generating the previous prodex answer).
+export function assertChatGptIdleAndReadyForPrompt(status) {
+    const busyBlocker = chatGptBusyBlocker(status.generating);
+    if (busyBlocker)
+        throw new ChatGptBrowserBlockerError(busyBlocker);
+    assertChatGptReadyForPrompt(inferChatGptPageLoggedInLikely(status), status.hasComposer, status.openDialogText);
+}
 export function assertChatGptReadyForPrompt(loggedInLikely, hasComposer, openDialogText) {
     if (loggedInLikely && hasComposer)
         return;
@@ -1416,16 +1430,20 @@ export async function sendChatGptPrompt(options) {
     if (blocker) {
         throw new ChatGptBrowserBlockerError(blocker);
     }
-    assertChatGptReadyForPrompt(inferChatGptPageLoggedInLikely(status), status.hasComposer, status.openDialogText);
-    if (normalizedTargetUrl)
-        assertChatGptTargetUrlMatches(status.url, normalizedTargetUrl);
-    assertVisibleChatGptTab(status.visibilityState, status.url, normalizedTargetUrl);
+    // Busy handling must run BEFORE the composer readiness assert: a thread
+    // still generating locks the composer, and asserting composer presence
+    // first misreports that as "missing a visible prompt composer" (see
+    // assertChatGptIdleAndReadyForPrompt). Default the queue budget to the send
+    // timeout: consults continue threads by default, so landing on a thread
+    // whose previous (often timed-out Pro) answer is still streaming is a when,
+    // not an if - queueing behind it beats failing.
     let busyBlocker = chatGptBusyBlocker(status.generating);
-    if (busyBlocker && (options.busyWaitMs ?? 0) > 0) {
+    const busyWaitBudgetMs = options.busyWaitMs ?? timeoutMs;
+    if (busyBlocker && busyWaitBudgetMs > 0) {
         // Queue behind the in-flight response instead of failing: shared-tab
         // contention (another agent or the user mid-generation) is a when, not an
         // if. Bounded, and a mid-wait page blocker (usage limit etc.) still throws.
-        const busyDeadline = Date.now() + (options.busyWaitMs ?? 0);
+        const busyDeadline = Date.now() + busyWaitBudgetMs;
         emitProgress("waiting", "tab busy with another response; waiting");
         while (busyBlocker && Date.now() < busyDeadline) {
             await sleep(3_000);
@@ -1437,10 +1455,16 @@ export async function sendChatGptPrompt(options) {
             if (busyBlocker)
                 emitProgress("waiting", "tab busy with another response; waiting");
         }
+        if (!busyBlocker) {
+            // The composer takes a moment to unlock after generation ends; settle
+            // again so the readiness assert below sees the reopened composer.
+            status = await readSettledChatGptPageStatus(page);
+        }
     }
-    if (busyBlocker) {
-        throw new ChatGptBrowserBlockerError(busyBlocker);
-    }
+    assertChatGptIdleAndReadyForPrompt(status);
+    if (normalizedTargetUrl)
+        assertChatGptTargetUrlMatches(status.url, normalizedTargetUrl);
+    assertVisibleChatGptTab(status.visibilityState, status.url, normalizedTargetUrl);
     emitProgress("tab_ready");
     // Progress details deliberately avoid project names (receipts redact them too).
     const selectionSummary = [
@@ -2205,37 +2229,23 @@ function win32ChromePaths(env) {
         "C:\\Program Files (x86)\\Microsoft\\Edge\\Application\\msedge.exe"
     ];
 }
-const WSL_WINDOWS_CHROME_PATHS = [
-    "/mnt/c/Program Files/Google/Chrome/Application/chrome.exe",
-    "/mnt/c/Program Files (x86)/Google/Chrome/Application/chrome.exe",
-    "/mnt/c/Program Files/Microsoft/Edge/Application/msedge.exe",
-    "/mnt/c/Program Files (x86)/Microsoft/Edge/Application/msedge.exe"
-];
-function kernelLooksLikeWsl() {
-    try {
-        return /microsoft/i.test(readFileSync("/proc/version", "utf8"));
-    }
-    catch {
-        return false;
-    }
-}
 /**
  * Ordered browser candidates for the current platform: PATH binary names
  * first, then well-known absolute install locations (macOS app bundles,
- * Windows Program Files/LOCALAPPDATA, and Windows-host browsers under WSL).
- * WSL detection cannot rely on WSL_DISTRO_NAME alone: non-login shells
- * (measured live) may not carry it, so WSL_INTEROP and the kernel string are
- * probed too.
+ * Windows Program Files/LOCALAPPDATA). Windows-host browsers are deliberately
+ * NOT candidates under WSL: auto-selecting a /mnt/c chrome.exe/msedge.exe
+ * either opened a blank window (the old --version probe - Windows browsers
+ * treat --version as a launch) or launched the user's Windows browser with a
+ * Linux profile path, both measured live as the recurring transient
+ * Edge+Chrome window spam. Under WSL the dedicated browser is a Linux chrome;
+ * a Windows browser is opt-in via PRODEX_CHROME only.
  */
-export function chromeCommandCandidates(platform = process.platform, env = process.env, isWsl = kernelLooksLikeWsl) {
+export function chromeCommandCandidates(platform = process.platform, env = process.env) {
     const candidates = [...CHROME_PATH_BINARY_NAMES];
     if (platform === "darwin")
         candidates.push(...DARWIN_CHROME_PATHS);
     if (platform === "win32")
         candidates.push(...win32ChromePaths(env));
-    if (platform === "linux" && (env.WSL_DISTRO_NAME || env.WSL_INTEROP || isWsl())) {
-        candidates.push(...WSL_WINDOWS_CHROME_PATHS);
-    }
     return candidates;
 }
 function resolveChromeCommand() {
@@ -2292,10 +2302,26 @@ function assertChromeLikeVersion(command, label) {
         throw new Error(`${label} must point to a Chrome/Chromium-compatible browser executable: ${command}`);
     }
 }
+// Windows chrome.exe/msedge.exe do not implement a console --version: they
+// treat it as a normal launch and open a visible blank window. Execing them to
+// probe was the source of the recurring transient Edge+Chrome window pairs on
+// WSL (trap-logged live: `cmd=msedge.exe --version parent=wslhost.exe`): under
+// system load the `google-chrome --version` probe exceeded its old 3s timeout,
+// the candidate walk fell through to the /mnt/c .exe paths, and each probe
+// spawned a blank window. The .exe candidates are fixed known install paths,
+// so file existence (checked by every caller) is the validation - never exec.
+export function isWindowsBrowserExecutablePath(command) {
+    return /\.exe$/i.test(command);
+}
 function hasChromeLikeVersion(command) {
+    if (isWindowsBrowserExecutablePath(command))
+        return true;
+    // 10s, not 3s: a loaded machine (e.g. a parallel test suite) can stall a
+    // cold `google-chrome --version` past 3s, and a false negative here used to
+    // cascade into the Windows .exe candidates above.
     const result = spawnSync(command, ["--version"], {
         encoding: "utf8",
-        timeout: 3000,
+        timeout: 10_000,
         maxBuffer: 1024 * 1024
     });
     const output = `${result.stdout ?? ""}\n${result.stderr ?? ""}`;

package/dist/cli-args.js

@@ -136,6 +136,16 @@ export function readPositiveIntegerFlag(args, flag) {
         throw new Error(`${flag} must be a positive integer`);
     return value;
 }
+export function readNonNegativeIntegerFlag(args, flag) {
+    // Like readPositiveIntegerFlag, but 0 is a meaningful opt-out (e.g.
+    // --busy-wait-ms 0 = fail fast instead of queueing behind a busy thread).
+    const value = readNumberFlag(args, flag);
+    if (value === undefined)
+        return undefined;
+    if (!Number.isInteger(value) || value < 0)
+        throw new Error(`${flag} must be a non-negative integer`);
+    return value;
+}
 export function readPortFlag(args, flag) {
     const value = readNumberFlag(args, flag);
     if (value === undefined)

package/dist/cli-pro.js

@@ -2,7 +2,7 @@ import { mkdir, readFile, writeFile } from "node:fs/promises";
 import path from "node:path";
 import { buildDryRunBundle } from "./bundle.js";
 import { DEFAULT_CDP_PORT, resolveCdpPort, chatGptVisibilityBlocker, defaultChatGptProfileDir, formatDurationMs, getChatGptBrowserStatus, listChatGptModelOptions, listChatGptSidebarProjects, normalizeChatGptTargetUrl, openChatGptBrowser, parseProMode, parseReasoningEffort, readLastBrowserLoginLaunch, recordBrowserLoginLaunch, recoverChatGptAnswerFromThread, sendChatGptPrompt } from "./chatgpt-browser.js";
-import { ASK_PRO_BOOLEAN_FLAGS, ASK_PRO_PREVIEW_VALUE_FLAGS, ASK_PRO_VALUE_FLAGS, assertHelpRequestArgs, assertNoExtraArgs, assertOnlyOptions, findHelpFlagIndexBeforePromptDelimiter, formatCliCommand, hasAskProDryRunMode, hasAskProMode, hasAskProSendMode, isHelpSubcommand, parseAskProArgs, printHelpIfRequested, readFlag, readPortFlag, readPositionalsWithOptions, readPositiveIntegerFlag, readRepeatedFlag, resolveCwdFlag, resolveOptionalFileFlag, unknownSubcommandError } from "./cli-args.js";
+import { ASK_PRO_BOOLEAN_FLAGS, ASK_PRO_PREVIEW_VALUE_FLAGS, ASK_PRO_VALUE_FLAGS, assertHelpRequestArgs, assertNoExtraArgs, assertOnlyOptions, findHelpFlagIndexBeforePromptDelimiter, formatCliCommand, hasAskProDryRunMode, hasAskProMode, hasAskProSendMode, isHelpSubcommand, parseAskProArgs, printHelpIfRequested, readFlag, readPortFlag, readPositionalsWithOptions, readNonNegativeIntegerFlag, readPositiveIntegerFlag, readRepeatedFlag, resolveCwdFlag, resolveOptionalFileFlag, unknownSubcommandError } from "./cli-args.js";
 import { printProBrowserHelp, printProHelp } from "./cli-help.js";
 import { listRawResultsForInspection, listTasksForInspection } from "./cli-ledger.js";
 import { formatBrowserDefaults, redactServerUrl } from "./cli-server.js";
@@ -692,7 +692,7 @@ export async function runAskProCommand(rest, io) {
         ...(selectionEffort ? { effort: selectionEffort } : {})
     };
     const browserPort = hasSendMode ? resolveCdpPort(readPortFlag(parsedAskPro.optionArgs, "--port")) : undefined;
-    const busyWaitMs = readPositiveIntegerFlag(parsedAskPro.optionArgs, "--busy-wait-ms");
+    const busyWaitMs = readNonNegativeIntegerFlag(parsedAskPro.optionArgs, "--busy-wait-ms");
     // Pro extended can legitimately think for minutes, so its default timeout is
     // higher; an explicit --timeout-ms always wins.
     // Pro reasoning routinely runs for many minutes (a real consult measured

package/dist/mcp.js

@@ -138,7 +138,7 @@ export function createServer(cwd = process.cwd(), options = {}) {
     const browserConsult = options.browserConsult;
     if (browserConsult) {
         server.registerTool("pro_consult", {
-            description: "Ask the user's logged-in ChatGPT (Pro) in the visible browser and wait for the full answer. This drives a real browser send: it can take minutes (Pro extended reasoning), is human-paced, and records a durable receipt under .bridge/. Requires a running `prodex pro browser login` session. By DEFAULT the consult continues in the currently-open thread, so consecutive follow-ups on the same topic stay in one conversation (keeps context, avoids sidebar clutter). Pass new_chat:true ONLY to start a fresh thread for a genuinely new topic. `project` and `model` come from saved defaults (per-repo config, or PRODEX_DEFAULT_PROJECT / PRODEX_DEFAULT_MODEL env vars) when omitted - do NOT pass them per-call unless deliberately overriding. Returns task_id, thread URL, and the answer text.",
+            description: "Ask the user's logged-in ChatGPT (Pro) in the visible browser and wait for the full answer. This drives a real browser send: it can take minutes (Pro extended reasoning), is human-paced, and records a durable receipt under .bridge/. Requires a running `prodex pro browser login` session. By DEFAULT the consult continues in the currently-open thread, so consecutive follow-ups on the same topic stay in one conversation (keeps context, avoids sidebar clutter). Pass new_chat:true ONLY to start a fresh thread for a genuinely new topic. If the thread is still generating a previous answer, the send automatically queues behind it (up to the timeout budget) - long 'tab busy' progress is normal, not stuck. `project` and `model` come from saved defaults (per-repo config, or PRODEX_DEFAULT_PROJECT / PRODEX_DEFAULT_MODEL env vars) when omitted - do NOT pass them per-call unless deliberately overriding. Returns task_id, thread URL, and the answer text.",
             inputSchema: {
                 prompt: McpBridgeTextSchema.min(1),
                 model: McpShortTextSchema.optional(),

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@youdie006/prodex",
-  "version": "0.16.31",
+  "version": "0.16.32",
   "description": "Local receipt bus for coordinating Codex execution with ChatGPT Pro/Projects consultation.",
   "author": "youdie006",
   "license": "MIT",