Initial run fails with {"name":"BunInstallFailedError","data":{"pkg":"opencode-scheduler","version":"latest"}}

[kkugot]

I am forced to use corporate registry (which proxies all requests), but need a custom bunfig.toml or --registry option passed for installations. On a Mac bun struggles to get .npmrc config. Removing the plugin from opencode.json in starter workspace does not help - it is then added again and the same error appears

[benjaminshafii]

thx for flagging @kkugot fixing it now

[benjaminshafii]

which platform are you on @kkugot ?

[qingkejane]

which platform are you on @kkugot ?

I meet this error on wins.

[tecaccc]

I also encountered this issue. The main reason is that I started the project via pnpm, and the bun tool was not installed on my Windows computer. After installing the tool and restarting, the issue was resolved. (Note: After installation, you need to restart the terminal for it to take effect.)

[kkugot]

Mac OS X Tahoe,
tried openwork 0.1.20, 0.1.23 - same issue

[Grypse]

Mac OS 26.2 With Openwork Version 0.1.23 (0.1.23) same issue. Opencode was already installed.

[benjaminshafii]

Automated note (bot): thanks — this is a real rough edge, especially for corporate networks.

What’s happening:

• The built-in “Starter” (and “Automation”) workspace presets currently force-add opencode-scheduler into opencode.json.
• OpenCode then tries to install/resolve that plugin at runtime (often via Bun). Behind a corporate registry / proxy, that can fail and you’ll see BunInstallFailedError.
• Even if you delete the plugin from opencode.json, OpenWork re-seeds required plugins for those presets during workspace bootstrap, which is why it “comes back”.

Workarounds right now:

• Create a new workspace using the “minimal” preset (no required plugins) and make it the active workspace before starting the engine.
• If you do want scheduler: configure Bun’s registry settings globally (e.g. via bunfig.toml) so the OpenCode process can resolve packages in your environment.

This conflicts with OpenWork’s onboarding goal (<5 min to first successful task, terminal-free), so we should change the presets to be more forgiving:

• don’t force-add scheduler in locked-down environments
• and/or add an explicit opt-in step + better error recovery

[Dielianss]

Got same issue with 0.2.2, and fixed it by installing opencode-scheduler via bum

[kkugot]

workspace manipulation helped

[cw1427]

Same error met on Windows with opencode 1.1.28 and openwork OpenWork_0.2.2_x64_en-US.msi

[SelectOne]

Same error on wins. "version":"latest"

[benjaminshafii]

Automated message: this is usually a registry/proxy issue when Bun installs opencode-scheduler. OpenWork currently uses Bun without a UI for registry overrides.

If you have a corporate registry, try setting BUN_CONFIG_REGISTRY or npm_config_registry before launching OpenWork. We’ll add a UI-level env var/config option so non‑terminal users aren’t blocked.

[kkugot]

I have created a wrapper around bun to run add/install and bunx with a proper config or registry. this resolves the issue system-wide, but not for openwork. Maybe it is not seeing bun at all? how does it execute the dependency install?

#!/usr/bin/env zsh
set -e

REAL="$HOME/.bun/bin/bun-real"
CONFIG_FILE="$HOME/.bunfig.toml"

cmd=""
has_config=false

# Detect subcommand and --config presence
for arg in "$@"; do
  if [[ "$arg" == "--config" || "$arg" == --config=* ]]; then
    has_config=true
  fi
  [[ "$arg" == -* ]] && continue
  cmd="$arg"
  break
done

case "$cmd" in
  install|add)
    if $has_config; then
      REGISTRY="$(npm config get registry 2>/dev/null || true)"
      if [[ -n "$REGISTRY" && "$REGISTRY" != "undefined" ]]; then
        exec "$REAL" "$@" --registry="$REGISTRY"
      else
        exec "$REAL" "$@"
      fi
    else
      echo exec "$REAL" "$@" --config="$CONFIG_FILE"
      exec "$REAL" "$@" --config="$CONFIG_FILE"
    fi
    ;;
  *)
    exec "$REAL" "$@"
    ;;
esac

[kkugot]

For now the only reliable way is to global install packages.