When a loopback profile (e.g., 'openclaw') is requested but no Chrome
executable is found on the system, the error message now suggests using
the configured remote default profile instead of the generic 'No
supported browser found' message.
This fixes browser tool failures in containerized deployments where:
1. The gateway has no local Chrome (runs in a minimal container)
2. A remote browser pod provides CDP access via a 'remote' profile
3. The agent LLM picks profile='openclaw' (the auto-created loopback
profile) because the tool schema had no guidance on profile selection
Changes:
- Export resolveBrowserExecutable() from chrome.ts for reuse
- Add pre-launch executable check in ensureBrowserAvailable() that
detects missing Chrome and suggests the remote default profile
- Improve error message in launchOpenClawChrome() to list available
remote profiles when local browser detection fails
- Add description to the profile parameter in the browser tool schema
to guide LLMs to omit the profile and use the default
- Add test harness mock for resolveBrowserExecutable
- Add test for the loopback-to-remote fallback behavior
* feat(telegram): support custom apiRoot for alternative API endpoints
Add `apiRoot` config option to allow users to specify custom Telegram Bot
API endpoints (e.g., self-hosted Bot API servers). Threads the configured
base URL through all Telegram API call sites: bot creation, send, probe,
audit, media download, and api-fetch. Extends SSRF policy to dynamically
trust custom apiRoot hostname for media downloads.
Closes#28535
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* fix(telegram): thread apiRoot through allowFrom lookups
* fix(telegram): honor lookup transport and local file paths
* refactor(telegram): unify username lookup plumbing
* fix(telegram): restore doctor lookup imports
* fix: document Telegram apiRoot support (#48842) (thanks @Cypherm)
---------
Co-authored-by: Cypherm <28184436+Cypherm@users.noreply.github.com>
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-authored-by: Ayaan Zaidi <hi@obviy.us>
- Added a test to ensure no warnings for legacy Brave config when bundled web search allowlist compatibility is applied.
- Updated validation logic to incorporate compatibility configuration for bundled web search plugins.
- Refactored the ensureRegistry function to utilize the new compatibility handling.
* test: align extension runtime mocks with plugin-sdk
Update stale extension tests to mock the plugin-sdk runtime barrels that production code now imports, and harden the Signal tool-result harness around system-event assertions so the channels lane matches current extension boundaries.
Regeneration-Prompt: |
Verify the failing channels-lane tests against current origin/main in an isolated worktree before changing anything. If the failures reproduce on main, keep the fix test-only unless production behavior is clearly wrong. Recent extension refactors moved Telegram, WhatsApp, and Signal code onto plugin-sdk runtime barrels, so update stale tests that still mock old core module paths to intercept the seams production code now uses. For Signal reaction notifications, avoid brittle assertions that depend on shared queued system-event state when a direct harness spy on enqueue behavior is sufficient. Preserve scope: only touch the failing tests and their local harness, then rerun the reproduced targeted tests plus the full channels lane and repo check gate.
* test: fix extension test drift on main
* fix: lazy-load bundled web search plugin registry
* test: make matrix sweeper failure injection portable
* fix: split heavy matrix runtime-api seams
* fix: simplify bundled web search id lookup
* test: tolerate windows env key casing
Reuse pi-ai's Anthropic client injection seam for streaming, and add
the OpenClaw-side provider discovery, auth, model catalog, and tests
needed to expose anthropic-vertex cleanly.
Signed-off-by: sallyom <somalley@redhat.com>
