# ElizaOS Developer Update (2026-05-04 → 2026-05-10)

This update summarizes core framework and plugin ecosystem changes landing around the week of **May 4–10, 2026**, plus notable developer discussions in Discord.

---

## 1) Core Framework

### Cross-platform secrets vault integrated end-to-end
The big architectural shift this cycle is the introduction and runtime/UI wiring of **`@elizaos/vault`** for secrets-at-rest and backend-routed secret resolution (OS keychain by default, with headless-safe fallbacks). This impacts how connector/model credentials are stored, revealed, and switched at runtime.

* PR: **`feat(vault): @elizaos/vault — cross-platform secrets vault + Settings UI integration`** ([elizaos/eliza#7197](https://github.com/elizaos/eliza/pull/7197))
* Follow-up hardening for headless Linux: **skip OS keychain on headless Linux to prevent native segfault on agent boot** ([elizaos/eliza#7230](https://github.com/elizaos/eliza/pull/7230))

**Key runtime behavior changes**
- Sensitive plugin settings saved via the Settings UI are now **mirrored into the vault** (encrypted at rest), while still writing the legacy `config.env.*` path for compatibility.
- Reveal flows prefer **vault-first** resolution (then fallback to env/config).
- Provider switching now supports storing references (`apiKeyRef`) instead of plaintext keys.

**Why it matters for developers**
- If you build custom plugins with “sensitive” config fields, validate that your parameter metadata correctly marks sensitive values; otherwise the vault mirror won’t engage.
- If you run headless Linux (CI, servers), ensure you’re on the post-fix vault master-key resolution path to avoid `libsecret`/D-Bus crashes (see #7230).

Docs:
- Vault package docs: `packages/vault/README.md` (in-repo, shipped with [#7197](https://github.com/elizaos/eliza/pull/7197))

---

## 2) New Features

### Slack connector migrated into the monorepo
Slack is now a first-class monorepo plugin under `plugins/plugin-slack/`, aligning it with the connector ecosystem and current core APIs.

* PR: **`feat(slack): migrate plugin-slack into the monorepo`** ([elizaos/eliza#7375](https://github.com/elizaos/eliza/pull/7375))

What you get:
- Socket Mode service + Slack formatting layer
- **11 actions** (send/edit/delete, pins, reactions, channel listing/reading, etc.)
- **3 providers** (channel state, member list, workspace info)
- 120 unit tests included with the migrated plugin

**Code example: enabling Slack**
```json
// ~/.eliza/eliza.json (or your branding config)
{
  "plugins": {
    "entries": {
      "@elizaos/plugin-slack": { "enabled": true }
    }
  }
}
```

Typical env/config fields (names may vary by your deployment):
```bash
export SLACK_BOT_TOKEN="xoxb-..."
export SLACK_APP_TOKEN="xapp-..." # for Socket Mode
```

Developer note: the migration included small API drift fixes (notably `State.recentMessagesData` typing and `MentionContext` shape). If you maintain downstream Slack forks, compare against monorepo `plugins/plugin-slack/src/service.ts` for current expectations.

---

### Cloud: monetized container app domains + app-scoped chat endpoint
Cloud capabilities expanded to support monetized app deployments with managed domains and an app-scoped chat endpoint.

* PR: **`feat(cloud): support monetized container app domains`** ([elizaos/eliza#7376](https://github.com/elizaos/eliza/pull/7376))

Highlights:
- App-scoped chat endpoint: `POST /api/v1/apps/:appId/chat`
- Domain management flows: check/buy/status/sync/verify with ownership checks
- Container deployment lifecycle improvements (monitor reconciliation)
- Skill/docs updates for the monetized app lifecycle

**API example: app-scoped chat**
```bash
curl -X POST "https://<cloud-host>/api/v1/apps/<appId>/chat" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <session-or-api-key>" \
  -d '{
    "messages": [{ "role": "user", "content": "Hello from my app!" }],
    "stream": false
  }'
```

Operational warning: this PR touches auth, billing/credits, CORS origin verification, and deployment state transitions. Review the PR notes and ensure you deploy Cloud API + frontend + control-plane together as instructed in [#7376](https://github.com/elizaos/eliza/pull/7376).

---

### LifeOps: analysis-mode / expanded action suite
A significant chunk of new “LifeOps” code landed, including an “analysis mode” and additional personal-ops actions, with extensive tests.

* PR: **`Add ilfeops code + analysis mode`** ([elizaos/eliza#7356](https://github.com/elizaos/eliza/pull/7356))

If you are embedding ElizaOS into a personal agent product, this is worth scanning for reusable extraction pipelines and invariants.

---

## 3) Bug Fixes (critical / developer-impacting)

### Headless Linux crash on boot (native segfault) when keychain is unavailable
Root cause: `@napi-rs/keyring` (libsecret backend) can segfault when no D-Bus Secret Service is reachable on headless Linux. This was addressed by skipping the OS keychain path and using safe fallbacks.

* Fix PR: [elizaos/eliza#7230](https://github.com/elizaos/eliza/pull/7230)

**Impact**
- Previously: process-level crash (not catchable in JS), agents would fail to start.
- Now: vault/confidant master-key selection avoids the dangerous path in headless environments.

---

### Windows CI false negatives for desktop installer smoke tests
Inno Setup on Windows Server 2025 can return “bogus” non-zero exit codes even when installation succeeds; smoke tests now tolerate those edge codes.

* Fix PR: [elizaos/eliza#7232](https://github.com/elizaos/eliza/pull/7232)

---

### Cloud auth/session reliability fixes (login & CLI flows)
A series of fixes tightened Cloudflare Pages routing, steward session behavior, and prevented client-side render loops / deadlocks on CLI login.

Notable PRs (see commit history for exact landing dates):
- Pages Functions consolidation / proxy correctness: [#7357](https://github.com/elizaos/eliza/pull/7357), [#7358](https://github.com/elizaos/eliza/pull/7358)
- Steward session + API client routing: [#7359](https://github.com/elizaos/eliza/pull/7359), [#7360](https://github.com/elizaos/eliza/pull/7360), [#7361](https://github.com/elizaos/eliza/pull/7361)
- CLI login completion deadlock fixes: [#7367](https://github.com/elizaos/eliza/pull/7367), [#7377](https://github.com/elizaos/eliza/pull/7377)
- Dashboard render loop fix: [#7374](https://github.com/elizaos/eliza/pull/7374)

---

## 4) API Changes (developer-facing)

### Secrets / plugin settings flows now support vault-backed storage and references
Changes introduced with vault integration ([#7197](https://github.com/elizaos/eliza/pull/7197)) include:
- **Plugin settings update route** now mirrors sensitive values into the vault and can report `vaultMirrorFailures`.
- **Reveal endpoint** prefers vault values before falling back to legacy env/config storage.
- New secrets-manager routing endpoints were introduced (see PR notes in [#7197](https://github.com/elizaos/eliza/pull/7197)).

**Migration guidance for custom tooling**
If you wrote internal automation that:
- Scrapes `config.env.*` plaintext values, or
- Assumes `apiKey` is always present in provider switch operations

…update it to tolerate:
- Vault references (`apiKeyRef`) and/or secret-manager references
- Vault-first reveal behavior

---

### Cloud: new app-scoped chat & managed domain endpoints
Introduced in [#7376](https://github.com/elizaos/eliza/pull/7376):
- `POST /api/v1/apps/:id/chat`
- Domain flows under `POST /api/v1/apps/:id/domains/*` (check/buy/status/sync/verify)
- Public app metadata route(s) for domain/app resolution

If you maintain a Cloud client, pin to the new routes and ensure you handle `401 not_signed_in` for unsigned chat requests (explicitly mentioned in the PR test plan).

---

## 5) Social Media Integrations (Twitter / Telegram / Discord / Farcaster / Slack)

### Slack
- Slack plugin is now monorepo-native ([#7375](https://github.com/elizaos/eliza/pull/7375)); treat the monorepo version as canonical going forward.

### Telegram (stability context + ongoing risk surface)
While the Discord discussions this week included only ops-cost and security questions, earlier identified Telegram issues remain relevant for developers deploying bots:
- Dual-poller races can cause silent message loss when two Telegraf instances poll the same token (see issue context: [elizaos/eliza#7245](https://github.com/elizaos/eliza/issues/7245)).
- Ensure you only have **one** polling owner per bot token (plugin vs wrapper) in your deployment topology.

### Discord
Recent work (from the broader May window) improved connector runtime context and configuration correctness:
- Discord connector target catalog service for real guild/channel enumeration (PR: [#7315](https://github.com/elizaos/eliza/pull/7315))
- Discord auto-reply configuration consistency tracked in plugin-discord repo (Issue/PR references in monthly summary: [plugin-discord#49](https://github.com/elizaos-plugins/plugin-discord/issues/49), [plugin-discord#50](https://github.com/elizaos-plugins/plugin-discord/pull/50))

### Twitter/X ops note (from Discord)
In `#coders`, operators reported Twitter bot costs dropping from **~$100/mo → ~$10/mo**, with cost dominated by reply volume and configuration choices. (Discord thread snapshot: https://discord.com/channels/1253563208833433701/1300025221834739744)

---

## 6) Model Provider Updates

### Dependency refreshes for AI SDK + provider libs
Multiple Renovate bumps landed around this period, including:
- `@anthropic-ai/sdk` update (e.g. [#7218](https://github.com/elizaos/eliza/pull/7218))
- `ai` SDK updates (e.g. [#7217](https://github.com/elizaos/eliza/pull/7217), [#7225](https://github.com/elizaos/eliza/pull/7225), [#7229](https://github.com/elizaos/eliza/pull/7229))
- `@ai-sdk/openai` updates (e.g. [#7214](https://github.com/elizaos/eliza/pull/7214), [#7223](https://github.com/elizaos/eliza/pull/7223), [#7227](https://github.com/elizaos/eliza/pull/7227))

**Developer action**
- If you maintain a custom provider plugin, re-run typechecks against the upgraded AI SDKs and ensure streaming/non-streaming response handlers still match current helper types.

### Secrets handling for provider credentials
With vault integration, model provider keys saved through Settings are expected to be stored via vault mirror. If you are instructing users to set `OPENAI_API_KEY`/`ANTHROPIC_API_KEY` manually, consider updating your docs to prefer Settings-based secret storage to avoid plaintext config drift.

---

## 7) Breaking Changes / V1 → V2 Migration Warnings

### ESM-first + monorepo consolidation continues
The ecosystem is converging on **ESM-first** and monorepo-native plugins. If you have older V1-era assumptions (CJS builds, standalone plugin repos, mixed language plugin layouts), expect friction.

Notable consolidation signal:
- Large repository restructuring: **add cloud and plugins, remove rust and python** ([elizaos/eliza#7235](https://github.com/elizaos/eliza/pull/7235))

**What can break**
- Import paths that assumed plugin sources lived outside the monorepo or had legacy build outputs.
- Tooling that expects Rust/Python artifacts in-tree for plugins that have moved to TS-only packaging within the monorepo.
- Build scripts that rely on CJS output or `require()` for plugin entrypoints.

### Credentials shape changes (vault references)
Even when backward compatibility exists, you should treat these as migration-impacting:
- Provider-switch operations can persist `apiKeyRef` instead of `apiKey` ([#7197](https://github.com/elizaos/eliza/pull/7197))
- “Reveal secret” flows prefer vault value; plaintext env/config may no longer be the source of truth after a Settings save.

**Recommended migration approach**
1. Update any internal scripts to resolve secrets via official reveal/secret-manager APIs rather than reading config files directly.
2. Ensure headless deployments have a master-key path available (passphrase/env fallback) so vault can function without OS secret services.

---

## Community / Ops Notes (Discord)
- **Security awareness surfaced**: a user asked whether something had been compromised, and another flagged a scam message, but no concrete incident details were posted publicly. Recommended follow-up: add a lightweight “security triage” checklist/runbook and encourage reporting with logs/artifacts in a private channel when compromise is suspected. (Context: https://discord.com/channels/1253563208833433701/1300025221834739744)

--- 

### Links Index
- Vault: [#7197](https://github.com/elizaos/eliza/pull/7197), headless Linux fix: [#7230](https://github.com/elizaos/eliza/pull/7230)  
- Slack monorepo migration: [#7375](https://github.com/elizaos/eliza/pull/7375)  
- Cloud monetized domains + app chat: [#7376](https://github.com/elizaos/eliza/pull/7376)  
- Repo consolidation: [#7235](https://github.com/elizaos/eliza/pull/7235)  
- Windows CI installer smoke fix: [#7232](https://github.com/elizaos/eliza/pull/7232)  
- Discord `#coders` ops-cost + security thread: https://discord.com/channels/1253563208833433701/1300025221834739744