* feat(tui): add local embedded TUI mode with terminal/chat aliases
Adds a gateway-free local TUI path so users can run openclaw in their
terminal without needing a running gateway process.
- TuiBackend interface abstraction (tui-backend.ts) with EmbeddedTuiBackend
implementation that drives the agent loop in-process
- openclaw tui --local flag for local embedded mode
- openclaw terminal / openclaw chat aliases that imply --local
- /auth slash command with codex CLI delegation to avoid prolite plan issue
- Default model display fallback on startup
- Local-aware status text and log suppression
- Concise auth error hints, raw HTML 403 suppression
- Onboarding hatch flow launches local TUI (no gateway required)
- Commander alias bug fix in run-main.ts (.aliases() check)
- All new and updated tests passing (145/145)
* TUI: fix alias detection, cross-platform codex lookup, and history byte-budget safeguards
* TUI: remove RuntimeEnv type annotation to fix CI oxlint error
* TUI: filter gateway-dependent tools and auto-approve plugin hooks in embedded mode
* TUI: suppress console noise and add embedded mode system prompt note
* TUI: reduce embedded-mode tool filtering from 15 to 7, add local session tools
* TUI: fix remaining PR review comments
* TUI: address latest review feedback and CI drift
* Core: align prompt helper with latest base
* Core: match prompt helper formatting with base
* Core: restore prompt helper from latest base
* fix(tui): preserve local auth fallback in source checkouts
* fix(tts): guard telephony provider invocation
* fix(tui): support Windows codex auth shim
* fix(tui): harden local auth flow
* fix: preserve embedded tool-first run events
* fix(tui): keep embedded plugin approvals gated
* fix(tui): restore embedded attempt import
* fix(tui): resolve sessions in embedded stub
* fix: add embedded TUI changelog entry (#66767) (thanks @fuller-stack-dev)
* fix: pass setup TUI local mode through relaunch (#66767) (thanks @fuller-stack-dev)
---------
Co-authored-by: Ayaan Zaidi <hi@obviy.us>
memory-core registers a gateway:startup hook that runs reconcileManagedDreamingCron() before deps.cron is attached to the startup event (the startup hook is deferred via a 250ms setTimeout in server.impl).
Downgrade the first startup-time "cron service unavailable" warning to a debug log, and rely on the existing runtime reconciliation path to warn if the cron service truly stays unavailable after boot. The managed dreaming cron job itself runs correctly — this was a log-noise regression, not a functional failure.
Signed-off-by: Sanjay Santhanam <51058514+Sanjays2402@users.noreply.github.com>
Wrap the `key in channel` probe inside the existing `try/catch` in `readDiscordChannelPropertySafe` so a throwing Proxy `has` trap (or any other reflective error on the presence check) degrades to `undefined` instead of propagating, matching the existing behavior for throwing getters on the value read.
Add a regression test that exposes the interaction channel through a Proxy whose `has` trap throws on `parentId` and asserts the slash-command path still defers and dispatches.
No behavior change for Carbon prototype getters or plain-object channels: the safe accessor still traverses the prototype chain (required for Carbon's `GuildThreadChannel.parentId`), still returns `undefined` for missing or throwing reads, and still preserves null-to-undefined coercion downstream.
The Carbon `GuildThreadChannel.parentId` getter throws "Cannot access rawData on partial Channel" whenever Discord delivers a partial thread (for example when an interaction channel is unhydrated). The existing `"parentId" in channel` guard did not help because the `in` operator returns true for prototype getters without invoking them, so the read still crashed `/new` and similar slash commands, guild reactions, and the native model picker when invoked from inside a thread.
Expose a `resolveDiscordChannelParentIdSafe` helper alongside the other channel accessors and use it everywhere we currently read `channel.parentId` from the inbound Discord channel. When the getter throws, the helper returns `undefined`, and the downstream code already falls back to re-fetching the thread id via `resolveDiscordChannelInfo`, keeping authorization/config lookups on the same inputs as before.
Add a regression test that installs a throwing `parentId` getter on a partial guild thread channel and asserts the slash-command path still defers and dispatches instead of surfacing an unauthorized reply.
Fixes#69861
