github-starred/ollama
2
0
Fork 0
mirror of https://github.com/ollama/ollama.git synced 2026-05-05 23:53:43 -05:00
Code Issues 14.5k Packages Projects Releases 120 Wiki Activity

[PR #15777] [MERGED] launch: harden OpenClaw onboarding flow #77599

New Issue
Closed
opened 2026-05-05 10:16:05 -05:00 by GiteaMirror · 0 comments
GiteaMirror commented 2026-05-05 10:16:05 -05:00
Owner
Copy Link

📋 Pull Request Information

Original PR: https://github.com/ollama/ollama/pull/15777
Author: @ParthSareen
Created: 4/23/2026
Status: ✅ Merged
Merged: 4/23/2026
Merged by: @ParthSareen

Base: main ← Head: parth-openclaw-setup-fixes

📝 Commits (4)

  • a771178 launch: stage bundled OpenClaw plugin deps
  • 66af5ac launch: own first OpenClaw gateway startup
  • 3616eb5 launch: wait for OpenClaw before passthrough tui
  • b822c3f launch: guard OpenClaw daemon-start fallback

📊 Changes

2 files changed (+459 additions, -28 deletions)

View changed files

📝 cmd/launch/openclaw.go (+94 -28)
📝 cmd/launch/openclaw_test.go (+365 -0)

📄 Description

Summary

  • stage OpenClaw bundled plugin runtime deps under a stable per-user directory
  • eagerly prepare bundled plugin deps during install, update, and onboard flows
  • make ollama launch openclaw own the first gateway startup instead of failing on OpenClaw's initial daemon health probe

Why

We were hitting two separate launch issues in the OpenClaw flow:

  1. Channel setup could fail inside OpenClaw's bundled extensions with missing runtime deps, especially during first-run setup paths.
  2. Fresh ollama launch openclaw runs could fail after installing the LaunchAgent because onboarding performed its own early health check before the launcher had a chance to bring the gateway up reliably.

These changes make the launcher more resilient without changing the user's intended setup flow.

Fixes

1. Bundled plugin runtime deps

  • set OPENCLAW_PLUGIN_STAGE_DIR to a stable directory under ~/.openclaw
  • use OPENCLAW_EAGER_BUNDLED_PLUGIN_DEPS=1 for install, update, and onboard paths
  • ensure npm install and OpenClaw update/onboard commands inherit that managed environment

This gives bundled extensions a predictable place to resolve their runtime dependencies and reduces failures during channel setup.

2. First-launch gateway startup

  • always pass --skip-health during non-interactive onboarding
  • keep daemon installation when available
  • after onboarding, try openclaw daemon start before falling back to gateway run --force

This shifts ownership of first-run startup to the launcher, which is already responsible for waiting on the gateway and continuing into the normal launch flow.

Testing

  • go test ./cmd/launch

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/ollama/ollama/pull/15777 **Author:** [@ParthSareen](https://github.com/ParthSareen) **Created:** 4/23/2026 **Status:** ✅ Merged **Merged:** 4/23/2026 **Merged by:** [@ParthSareen](https://github.com/ParthSareen) **Base:** `main` ← **Head:** `parth-openclaw-setup-fixes` --- ### 📝 Commits (4) - [`a771178`](https://github.com/ollama/ollama/commit/a771178fabd5a43da6fd906acfe3eec894198405) launch: stage bundled OpenClaw plugin deps - [`66af5ac`](https://github.com/ollama/ollama/commit/66af5ac6dcccbbbd4e25bdf60b21734034938826) launch: own first OpenClaw gateway startup - [`3616eb5`](https://github.com/ollama/ollama/commit/3616eb59308a03035ad0801bb330b4f3cb895044) launch: wait for OpenClaw before passthrough tui - [`b822c3f`](https://github.com/ollama/ollama/commit/b822c3ff52c189e26b6b80af59dc8a49b60e452a) launch: guard OpenClaw daemon-start fallback ### 📊 Changes **2 files changed** (+459 additions, -28 deletions) <details> <summary>View changed files</summary> 📝 `cmd/launch/openclaw.go` (+94 -28) 📝 `cmd/launch/openclaw_test.go` (+365 -0) </details> ### 📄 Description ## Summary - stage OpenClaw bundled plugin runtime deps under a stable per-user directory - eagerly prepare bundled plugin deps during install, update, and onboard flows - make `ollama launch openclaw` own the first gateway startup instead of failing on OpenClaw's initial daemon health probe ## Why We were hitting two separate launch issues in the OpenClaw flow: 1. Channel setup could fail inside OpenClaw's bundled extensions with missing runtime deps, especially during first-run setup paths. 2. Fresh `ollama launch openclaw` runs could fail after installing the LaunchAgent because onboarding performed its own early health check before the launcher had a chance to bring the gateway up reliably. These changes make the launcher more resilient without changing the user's intended setup flow. ## Fixes ### 1. Bundled plugin runtime deps - set `OPENCLAW_PLUGIN_STAGE_DIR` to a stable directory under `~/.openclaw` - use `OPENCLAW_EAGER_BUNDLED_PLUGIN_DEPS=1` for install, update, and onboard paths - ensure npm install and OpenClaw update/onboard commands inherit that managed environment This gives bundled extensions a predictable place to resolve their runtime dependencies and reduces failures during channel setup. ### 2. First-launch gateway startup - always pass `--skip-health` during non-interactive onboarding - keep daemon installation when available - after onboarding, try `openclaw daemon start` before falling back to `gateway run --force` This shifts ownership of first-run startup to the launcher, which is already responsible for waiting on the gateway and continuing into the normal launch flow. ## Testing - `go test ./cmd/launch` --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
GiteaMirror added the pull-request label 2026-05-05 10:16:05 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
amd
api
app
bug
build
cli
cloud
compatibility
context-length
create
docker
documentation
embeddings
feature request
feedback wanted
good first issue
gpt-oss
gpu
harmony
help wanted
image
install
intel
js
launch
linux
macos
memory
mlx
model
needs more info
networking
nvidia
ollama.com
performance
pull-request
Mirrored from GitHub Pull Request
 python
question
registry
rendering
thinking
tools
top
vulkan
windows
wsl
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/ollama#77599
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?