MEMORY.md is now loaded into context at session start, ensuring the
agent has access to curated long-term memory without requiring
embedding-based semantic search.
Previously, MEMORY.md was only accessible via the memory_search tool,
which requires an embedding provider (OpenAI/Gemini API key or local
model). When no embedding provider was configured, the agent would
claim memories were empty even though MEMORY.md existed and contained
data.
This change:
- Adds DEFAULT_MEMORY_FILENAME constant
- Includes MEMORY.md in WorkspaceBootstrapFileName type
- Loads MEMORY.md in loadWorkspaceBootstrapFiles()
- Does NOT add MEMORY.md to subagent allowlist (keeps user data private)
- Does NOT auto-create MEMORY.md template (user creates as needed)
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
* docs: Add Oracle Cloud (OCI) platform guide
- Add comprehensive guide for Oracle Cloud Always Free tier (ARM)
- Cover VCN security, Tailscale Serve setup, and why traditional hardening is unnecessary
- Update vps.md to list Oracle as top provider option
- Update digitalocean.md to link to official Oracle guide instead of community gist
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* Keep community gist link, remove unzip
* Fix step order: lock down VCN after Tailscale is running
* Move VCN lockdown to final step (after verifying everything works)
* docs: make Oracle/Tailscale guide safer + tone down DO copy
* docs: fix Oracle guide step numbering
* docs: tone down VPS hub Oracle blurb
* docs: add Oracle Cloud guide (#2333) (thanks @hirefrank)
---------
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
Co-authored-by: Pocket Clawd <pocket@Pockets-Mac-mini.local>
Plugin commands can return buttons in channelData.telegram.buttons,
but deliverReplies() was ignoring them. Now we:
1. Extract buttons from reply.channelData?.telegram?.buttons
2. Build inline keyboard using buildInlineKeyboard()
3. Pass reply_markup to sendMessage()
Buttons are attached to the first text chunk when text is chunked.
Plugin commands were added to setMyCommands menu but didn't have
bot.command() handlers registered. This meant /flow-start and other
plugin commands would fall through to the general message handler
instead of being dispatched to the plugin command executor.
Now we register bot.command() handlers for each plugin command,
with full authorization checks and proper result delivery.
- Add plugin command specs to Telegram setMyCommands for autocomplete
- Export GatewayRequestHandler types in plugin-sdk for plugin authors
- Enables plugins to register gateway methods and appear in command menus
Add sendPayload handler to Telegram outbound adapter to support
channel-specific data via the channelData pattern. This enables
features like inline keyboard buttons without custom ReplyPayload fields.
Implementation:
- Extract telegram.buttons from payload.channelData
- Pass buttons to sendMessageTelegram (already supports this)
- Follows existing sendText/sendMedia patterns
- Completes optional ChannelOutboundAdapter.sendPayload interface
This enables plugins to send Telegram-specific features (buttons, etc.)
using the standard channelData envelope pattern instead of custom fields.
Related: delivery system in src/infra/outbound/deliver.ts:324 already
checks for sendPayload handler and routes accordingly.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
- Add fly.private.toml template for deployments with no public IP
- Add "Private Deployment (Hardened)" section to Fly docs
- Document how to convert existing deployment to private-only
- Add security notes recommending env vars over config file for secrets
This addresses security concerns about Clawdbot gateways being
discoverable on internet scanners (Shodan, Censys). Private deployments
are accessible only via fly proxy, WireGuard, or SSH.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* feat(discord): add configurable privileged Gateway Intents (GuildPresences, GuildMembers)
Add support for optionally enabling Discord privileged Gateway Intents
via config, starting with GuildPresences and GuildMembers.
When `channels.discord.intents.presence` is set to true:
- GatewayIntents.GuildPresences is added to the gateway connection
- A PresenceUpdateListener caches user presence data in memory
- The member-info action includes user status and activities
(e.g. Spotify listening activity) from the cache
This enables use cases like:
- Seeing what music a user is currently listening to
- Checking user online/offline/idle/dnd status
- Tracking user activities through the bot API
Both intents require Portal opt-in (Discord Developer Portal →
Privileged Gateway Intents) before they can be used.
Changes:
- config: add `channels.discord.intents.{presence,guildMembers}`
- provider: compute intents dynamically from config
- listeners: add DiscordPresenceListener (extends PresenceUpdateListener)
- presence-cache: simple in-memory Map<userId, GatewayPresenceUpdate>
- discord-actions-guild: include cached presence in member-info response
- schema: add labels and descriptions for new config fields
* fix(test): add PresenceUpdateListener to @buape/carbon mock
* Discord: scope presence cache by account
---------
Co-authored-by: kugutsushi <kugutsushi@clawd>
Co-authored-by: Shadow <hi@shadowing.dev>
