🔴 "unanswered" metadata written before all skip conditions, permanently suppressing the prompt on transient failures

The "unanswered" metadata file is written at line 93-99, before agent detection (line 104), the no-agents check (line 113), and the non-interactive terminal check (line 121). If any of these checks cause an early return, the "unanswered" file remains on disk. On every subsequent run, readSkillsInstallMetadataFile() returns the existing config at agents-skills-install.ts:60-61, so the function enters the early-return block at line 61 and returns at line 75 — permanently suppressing the prompt.

This is a regression from the old code (agents-skills-install.ts:71-92 in the base commit) which only wrote metadata after the user answered the prompt. Affected scenarios:

• Non-interactive terminal: User runs wrangler once in a non-TTY environment (e.g., piped output, IDE task runner). The "unanswered" file is created. On the next interactive run, the prompt is silently skipped.
• Agent detection failure: WASM load fails once (a transient error). The prompt is permanently suppressed even after agents are installed.
• No agents detected: User runs wrangler before installing any AI coding agent. After installing one, they still never see the prompt.

The fix is to move the "unanswered" write to just before the prompt (after all skip conditions), or delete the metadata file in the early-return paths.

The writeSkillsInstallMetadataFile call at lines 93-100 is placed too early in the function — before agent detection (line 104), the no-agents check (line 113), and the non-interactive terminal check (line 121). If any of these subsequent checks triggers an early return, the 'unanswered' metadata file is left on disk, permanently suppressing the prompt on future runs.

The intent of writing 'unanswered' early is to (a) handle concurrent instances and (b) survive interruptions during the slow agent-detection WASM load. But the current placement also covers cases where the prompt was never going to be shown (no agents, non-interactive terminal, detection failure), which is a regression from the old behavior.

Approach 1 (recommended): Move the writeSkillsInstallMetadataFile call to just before the prompts() call — after the agent detection, no-agents check, and isInteractive check all pass. This preserves the concurrency protocol (the PID check before the prompt) while not leaving stale metadata when the prompt wouldn't be shown. The tradeoff is that a crash during agent detection won't leave a marker, but agent detection is a local WASM operation that's unlikely to be interrupted.

Approach 2: Keep the early write but delete or overwrite the metadata file in each of the early-return paths (agent detection failure at line 110, no agents at line 117, non-interactive at line 125). This would require calling something like deleteSkillsInstallMetadataFile() or writing metadata with accepted: false in each path.

Files to modify: packages/wrangler/src/agents-skills-install.ts (move or add cleanup in the early return paths). Also update the pre-prompt PID re-read at line 137-140 if the write is moved later.

Was this helpful? React with 👍 or 👎 to provide feedback.

🚩 Concurrent instance protocol leaves prompt permanently suppressed after concurrency resolves

By design, when two wrangler instances run concurrently, neither shows the prompt. The metadata file ends up with accepted: "unanswered" and the second instance's PID. On ALL subsequent single-instance runs, the function sees the existing "unanswered" metadata at agents-skills-install.ts:61, overwrites the PID at line 68-73, and returns at line 75 — the user is never prompted again. This is the stated intent of the PR ("any interruption leaves behind a file that prevents the prompt from resurfacing"), but it means a single concurrent-run incident permanently disables the feature. Users must manually run wrangler --install-skills to recover. Consider whether a TTL or retry mechanism for "unanswered" state would be more user-friendly.

Was this helpful? React with 👍 or 👎 to provide feedback.

🚩 Metrics are lost on Ctrl+C due to process.exit(1) via nextTick

The old code (base commit) sent a "User dismissed (SIGINT)" metrics event and awaited allMetricsDispatchesCompleted() before calling process.exit(1), ensuring the metrics dispatch completed. The new code schedules process.exit(1) via process.nextTick in the onState callback at line 189-191, which fires before the async continuation can send any metrics event. This means Ctrl+C dismissals are no longer tracked in telemetry at all. The allMetricsDispatchesCompleted import was also removed (line 16 in the diff). This may be acceptable since the "unanswered" state conflates multiple scenarios anyway, but it's a loss of telemetry signal compared to the old code.

Was this helpful? React with 👍 or 👎 to provide feedback.