[verify-packaged-daemon-entry] could not launch daemon-entry

Error message

[verify-packaged-daemon-entry] could not launch daemon-entry.js: ${result.error.message}

What it means

Thrown by the packaged daemon entry verification script when spawnSync(execPath, [entryPath]) returns a result with an error property set. This means Node.js could not even spawn the process to run daemon-entry.js — the failure is at the OS/process level (e.g., the execPath binary doesn't exist, the entry file permissions prevent execution, or the system is out of resources), not a JavaScript module-loading failure.

Source

Thrown at config/scripts/verify-packaged-daemon-entry.cjs:39

}

// Why: v1.4.129-rc.1 shipped a terminal daemon that could not load (an electron
// `require` leaked into its bundle) while every build check passed. This boots
// the PACKAGED daemon-entry under plain Node against the asar-unpacked layout,
// so a bundling / asar-unpack regression fails packaging instead of reaching
// users. Module-load proof only: with no args the entry must reach argv parsing
// and print its "Usage: daemon-entry" error — a MODULE_NOT_FOUND or a missing
// usage line means the packaged graph does not load and the build must fail.
//
// resourcesDir is the packaged Resources dir (Contents/Resources on macOS,
// <appOutDir>/resources elsewhere). execPath defaults to the packaging Node.
function verifyPackagedDaemonEntryBoots(resourcesDir, options = {}) {
  const execPath = options.execPath || process.execPath
  const entryPath = assertPackagedDaemonEntryExists(resourcesDir)

  const result = spawnSync(execPath, [entryPath], { encoding: 'utf8', timeout: 10_000 })
  if (result.error) {
    throw new Error(
      `[verify-packaged-daemon-entry] could not launch daemon-entry.js: ${result.error.message}`
    )
  }
  const stderr = result.stderr || ''
  if (/Cannot find module|MODULE_NOT_FOUND/.test(stderr)) {
    throw new Error(
      `[verify-packaged-daemon-entry] packaged daemon-entry.js failed to load under plain Node:\n${stderr}`
    )
  }
  if (!stderr.includes('Usage: daemon-entry')) {
    throw new Error(
      `[verify-packaged-daemon-entry] packaged daemon-entry.js did not reach argv parsing ` +
        `(expected the "Usage: daemon-entry" error). stderr:\n${stderr}`
    )
  }
  console.log('[verify-packaged-daemon-entry] OK — packaged daemon-entry loads under plain Node')
}

View on GitHub (pinned to 1136503c6a)

Solutions

Inspect result.error.message in the thrown error — for ENOENT it indicates which path is missing, for EACCES it's a permissions issue.
Verify process.execPath points to a valid, executable Node binary: ls -la $(which node).
Check file permissions on the entry path: it must be readable by the process running the verification.
If running in a container, ensure the Node binary and the packaged resources are both present and accessible inside the container filesystem.

Defensive patterns

Strategy: try-catch

Validate before calling

// Verify the Node binary is executable before spawning.
const { existsSync, accessSync, constants } = require('node:fs')

function preCheckExecPath(execPath) {
  if (!existsSync(execPath)) {
    throw new Error(`execPath does not exist: ${execPath}`)
  }
  try {
    accessSync(execPath, constants.X_OK)
  } catch {
    throw new Error(`execPath is not executable: ${execPath}`)
  }
}

Try / catch

// spawnSync errors are at the OS level; distinguish ENOENT from EACCES.
try {
  verifyPackagedDaemonEntryBoots(resourcesDir)
} catch (error) {
  if (error.message.includes('could not launch')) {
    // OS-level failure — check binary, permissions, or container setup
    console.error('Launch failure — verify execPath and file permissions:', error.message)
  }
  throw error
}

Prevention

In containerized CI, verify process.execPath resolves to a real binary inside the container, not a host path leaked through volume mounts.
Check that the packaged resources directory has correct read permissions for the CI user.

When it happens

Trigger: The execPath (defaults to process.execPath, i.e. the Node binary running the verification) doesn't exist or isn't executable at the resolved path; the entryPath file has restrictive permissions; a broken symlink at the entry path; the OS refused to fork the process (out of memory, too many processes).

Common situations: Running the verification inside a CI container where the Node binary path differs from what process.execPath resolved to at packaging time; the packaged app was built on a different OS and the entry file has wrong permissions; a disk-full or resource-exhausted CI runner; the asar-unpacked path is a dangling symlink.

Related errors

AI-assisted analysis of stablyai/orca@1136503c6a (2026-08-12). Data as JSON: /api/errors/40cfadf615e97bd3. Report an issue: GitHub.