# ElizaOS Developer Update (2026-05-07 → 2026-05-13)

This update summarizes framework + plugin ecosystem changes landing on `elizaos/eliza` during the last week, plus notable developer discussions from Discord.

---

## 1) Core Framework

### `@elizaos/vault`: encrypted secrets + runtime/UI wiring
The vault subsystem landed as a first-class workspace package, enabling **encryption-at-rest** for sensitive config while keeping backward compatibility with existing `config.env.*` flows.

Key technical pieces:
- New package: **`@elizaos/vault`** (AES-256-GCM envelopes, OS keychain master-key by default, headless passphrase fallback).
- Settings UI + server routes now mirror sensitive plugin fields into the vault and prefer vault values on “reveal”.
- Runtime operations shifted toward **reference-based secrets** (store `apiKeyRef`, resolve at runtime via vault), with hydration-time migration from plaintext.
- Headless Linux stability fix: skip OS keychain paths when Secret Service is unavailable to avoid native crashes.

Links:
- PR: `feat(vault): @elizaos/vault — cross-platform secrets vault + Settings UI integration` **#7197**  
  https://github.com/elizaos/eliza/pull/7197
- PR: `fix(vault, confidant): skip OS keychain on headless Linux to prevent native segfault on agent boot` **#7230**  
  https://github.com/elizaos/eliza/pull/7230
- PR: `fix(agent): skip vault sentinels in applyConfigEnvToProcessEnv` **#7368**  
  https://github.com/elizaos/eliza/pull/7368

**Developer-facing behavior:** saving keys in Settings now writes an encrypted entry; API responses reveal from vault-first, and provider switching persists references.

---

### Monorepo consolidation: Cloud + plugins brought into-tree
A large consolidation PR moved more Cloud + plugin surfaces into the main repo and removed legacy multi-language remnants (Rust/Python) from the monorepo build graph.

Link:
- PR: `chore: add cloud and plugins, remove rust and python` **#7235**  
  https://github.com/elizaos/eliza/pull/7235

**Implication for contributors:** build/test pipelines increasingly assume a TS/Bun-first workflow inside this monorepo.

---

## 2) New Features

### Slack connector is now a monorepo plugin
`@elizaos/plugin-slack` has been migrated into `plugins/plugin-slack/` with a full actions/providers surface and a substantial unit test suite.

What ships:
- **11 actions** (send/edit/delete, channel operations, pins, reactions, user info, emoji list, etc.)
- **3 providers** (channel state, member list, workspace info)
- Socket Mode service implementation
- ~120 unit tests

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

**Note:** The PR discussion flagged a potential message-drop risk if Slack user lookup throws inside event handlers (missing try/catch). If you’re running Slack in production, consider wrapping `users.info` calls defensively until a follow-up hardening PR lands.

---

### Cloud: monetized container app domains + app-scoped chat endpoint
Cloud gained the production path for agent-built monetized apps, including app-scoped chat, domain lifecycle, and deployment reconciliation.

Highlights:
- New endpoint: **`POST /api/v1/apps/:appId/chat`** (app-scoped chat with monetization metadata & provider routing)
- Cloudflare-managed domain flows: check/buy/status/sync/verify
- App auth callback/session handling for generated apps
- Container deploy monitor reconciliation so healthy deployments move `deploying → running`

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

**Heads-up for Cloud operators:** this PR was marked “large risk” and also surfaced review concerns (auth errors being returned as 500 for API-key callers; domain sync not marking `verified`). If you deploy Cloud from `develop`, validate these edge cases in staging against your auth + CORS expectations.

---

### Automations (n8n): end-to-end clarification loop + UI quick-picks
The n8n workflow generation path now supports a full “needs clarification” roundtrip from model → server → UI → resolve.

Links:
- PR: `feat(n8n): clarification roundtrip route` **#7316**  
  https://github.com/elizaos/eliza/pull/7316
- PR: `feat(automations): clarification quick-pick UI` **#7341**  
  https://github.com/elizaos/eliza/pull/7341
- PR: `feat(n8n-workflow): structured ClarificationRequest + name->id prompt rules` **#7373**  
  https://github.com/elizaos/eliza/pull/7373

---

### Self-hosted runtime: CORS + bearer auth + cross-platform build fixes
Self-hosting support improved for browser dashboards and remote agent connectivity, including HTTPS/CORS hardening and bearer auth support.

Link:
- PR: `feat(self-hosted): CORS + bearer auth + cross-platform build fixes` **#7212**  
  https://github.com/elizaos/eliza/pull/7212

---

## 3) Bug Fixes (critical / high-impact)

### Headless Linux segfault on boot (keyring/libsecret)
Root cause: native keyring backend attempting Secret Service calls in environments without DBus/Secret Service (common on headless servers/CI) could segfault the process.

Fix: short-circuit OS keychain usage on headless Linux and fall back to passphrase/env master key paths.

Link:
- PR: **#7230** https://github.com/elizaos/eliza/pull/7230

---

### Registry ID collision: app vs plugin entries
A hard failure in the registry loader occurred because both an app entry and a plugin entry used `id: "polymarket"`; the loader enforces globally unique IDs.

Fix: rename plugin entry ID to avoid collision.

Link:
- PR: `fix(registry): rename plugin polymarket id to avoid app/plugin collision` **#7314**  
  https://github.com/elizaos/eliza/pull/7314

---

### Automations deletion bug: wrong trigger identifier passed from detail pane
A P1 UX/data integrity issue where deletion invoked `onDeleteTrigger(trigger.id)` while the confirmation dialog used the display name (and could mismatch the intended target).

Fix: pass `triggerName` through the delete path.

Link:
- PR: `fix(automations): pass triggerName to onDeleteTrigger from detail pane` **#7340**  
  https://github.com/elizaos/eliza/pull/7340

---

### n8n workflow parsing: tolerate prose after JSON
Even when requesting JSON output, models may append trailing conversational text after the JSON object, breaking strict parsers.

Fix: loosen parsing to tolerate prose-trailed JSON.

Link:
- PR: `fix(n8n-workflow): tolerate prose-trailed JSON in parseWorkflowResponse` **#7369**  
  https://github.com/elizaos/eliza/pull/7369

---

### Cloud frontend auth stability (CLI login + steward session)
Several fixes landed to stop render loops, deadlocks, and routing/proxy drift in Cloudflare Pages deployments.

Representative links:
- `fix(cloud-frontend): cli-login completion effect deadlock` **#7367**  
  https://github.com/elizaos/eliza/pull/7367
- `fix(cloud-frontend): cli-login active flag race on cleanup` **#7377**  
  https://github.com/elizaos/eliza/pull/7377
- `fix(cloud): stop billing-fetch render-loop in CloudDashboard` **#7374**  
  https://github.com/elizaos/eliza/pull/7374
- SIWE unblock + env correctness:
  - **#7324** https://github.com/elizaos/eliza/pull/7324
  - **#7327** https://github.com/elizaos/eliza/pull/7327

---

## 4) API Changes

### Secrets + plugin configuration routes (vault integration)
If you maintain tooling that automates plugin configuration, be aware of vault-first behaviors and secret reference persistence:

- Sensitive fields saved via plugin config are **mirrored to vault** and may now be represented/handled as references (`apiKeyRef`) downstream.
- Reveal flows consult vault first, then fallback to legacy env/config.

Primary link:
- PR: **#7197** https://github.com/elizaos/eliza/pull/7197

**Example: using `@elizaos/vault` directly**
```ts
import { sharedVault } from "@elizaos/vault";

// Store sensitive secret (encrypted at rest)
await sharedVault().set("OPENAI_API_KEY", process.env.OPENAI_API_KEY!, {
  sensitive: true,
});

// Retrieve
const key = await sharedVault().get("OPENAI_API_KEY");
```

---

### Cloud app-scoped chat endpoint
New production endpoint for monetized apps:

- `POST /api/v1/apps/:appId/chat`

Link:
- PR: **#7376** https://github.com/elizaos/eliza/pull/7376

**Example request**
```bash
curl -X POST "https://api.elizacloud.ai/api/v1/apps/$APP_ID/chat" \
  -H "content-type: application/json" \
  -H "authorization: Bearer $APP_USER_TOKEN" \
  -d '{
    "messages": [{ "role": "user", "content": "Hello from my app" }],
    "stream": false
  }'
```

---

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

### Slack (newly integrated into monorepo)
See **#7375** above.

### Discord: connector target catalog (for automation context)
A new catalog service surfaces real Discord guild/channel targets to support automation and clarification flows.

Link:
- PR: `feat(app-core): connector-target-catalog service (Discord)` **#7315**  
  https://github.com/elizaos/eliza/pull/7315

### Telegram
No new Telegram code landed in the provided weekly slice, but Discord discussion continues to highlight operational concerns (and earlier fixes addressed polling races and config propagation). If you run Telegram bots, watch for connector/plugin duplication issues and ensure only a single poller is active per token (see historical issue context: **#7245**, now closed).

---

## 6) Model Provider Updates

### Anthropic SDK bump
Link:
- PR: `fix(deps): update dependency @anthropic-ai/sdk to ^0.92.0` **#7218**  
  https://github.com/elizaos/eliza/pull/7218

### AI SDK / OpenAI provider packages updated
A series of dependency bumps landed for `ai`, `@ai-sdk/openai`, provider utils, etc. These can affect streaming semantics, tool calling, and provider option validation—pin versions carefully in downstream apps if you rely on specific behavior.

Representative PRs:
- `@ai-sdk/openai` updates: **#7214**, **#7223**, **#7227**  
- `ai` updates: **#7217**, **#7225**, **#7229**

(See merged PR list in repo activity for exact pins.)

---

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

### V2 plugin registry submission is currently blocked (404)
Discord reports that both the registry repo and the hosted registry endpoint were returning 404, preventing third-party plugin submissions—especially important for BUSL-1.1 licensed plugins that cannot PR directly to the monorepo.

Discussion context (Discord, 2026-05-12):
- Registry repo: `elizaos-plugins/registry` returning 404
- Endpoint: `plugins.elizacloud.ai` returning 404
- Core team is investigating; a policy change may revert to PRs directly against `elizaos/eliza` temporarily.

Links:
- Discord thread (coders): https://discord.com/channels/1253563208833433701/1300025221834739744

**Action for plugin authors (V2):**
- If you were preparing registry JSON + submission PRs, **pause** until the registry access issue is resolved or until the team confirms the fallback PR path to `elizaos/eliza`.
- If your plugin is BUSL-1.1 licensed, call this out early—submission path may differ by license constraints.

---

### Secret handling: plaintext keys → references (`apiKeyRef`)
With vault integration, some flows now store references instead of plaintext secrets. If you have custom tooling that:
- reads `config.env.*` directly, or
- expects provider switch operations to include `apiKey`,
you should update it to handle `apiKeyRef` + vault resolution.

Primary link:
- PR: **#7197** https://github.com/elizaos/eliza/pull/7197

---

### Build/runtime expectations after consolidation
The monorepo consolidation PR (**#7235**) removed Rust/Python surfaces from the mainline workspace. If you relied on those legacy build steps in CI, you’ll need to re-align pipelines to the current Bun/TS workflow or use separate tooling repos.

Link:
- PR: **#7235** https://github.com/elizaos/eliza/pull/7235