oh-my-opencode >= v4.7 removed the 'mcp start' subcommand but the installer still writes a local MCP config entry pointing to it. Built-in MCP servers (websearch, context7, grep_app, lsp) are remote HTTP and registered by the plugin itself. After running the installer, clean up the MCP section so OpenCode doesn't try to start the nonexistent command.
Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>
When the resolver detects a non-AVX2 CPU, reinstall Bun via its own install script before running oh-my-opencode. Bun's installer reads /proc/cpuinfo and auto-selects the baseline variant, which runs on older x64 CPUs. Export BUN_VERSION as an ENV in the Dockerfile so the install script can target the same version at runtime.
Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>
Replace platform-specific npm package resolution with the meta-package oh-my-opencode and OH_MY_OPENCODE_FORCE_BASELINE=1 env export. The meta-package's JS wrapper handles baseline binary selection, avoiding npm exec binary-not-found errors with platform-specific packages while still supporting non-AVX2 hosts. Also works around the OMO_PACKAGE env var leakage issue by making resolver always output the meta-package name.
Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>
Run oh-my-opencode through npm exec instead of bunx so non-AVX2 hosts can install the baseline package without Bun crashing before the package entrypoint runs. Keep the existing package resolver in place so doctor, smoke, and auto-install all follow the same compatibility path.
Make the workstation image select architecture-appropriate oh-my-opencode packages and stop assuming AVX2-capable amd64 hosts. Also upgrade Bun and make the bundled Go download respect the target container architecture so the image builds and installs more reliably across supported platforms.