# ElizaOS Developer Update — 2026-02-02 to 2026-02-06

## 1) Core Framework

### Agent runtime: autonomous mode is now “default-first”
In core discussion this week, the team reiterated that autonomous mode is no longer “just a plugin toggle” but a first-class runtime behavior. The recommended instantiation pattern is:

```ts
import { AgentRuntime } from "@elizaos/core";

const agentRuntime = new AgentRuntime({
  autonomous: true,
});
```

**Why this matters:** plugin authors should assume scheduled tasks / heartbeats may be running continuously (and plan for rate limiting + idempotency), especially for skills that call external APIs or mutate state.

### Skill ecosystem + security posture (cskills / clawhub concerns)
Ongoing work/concerns were raised around malicious or low-quality “skills” in the wider ecosystem (specifically clawhub). The proposed multi-layer strategy discussed:

- **Scanner skills** to statically inspect packages before install/run
- A **rewrite/adaptation phase** to transform packaged code into Eliza-compatible skill shape
- **LLM-based review** to flag suspicious behavior patterns
- Possible **sandboxing** as a hard isolation boundary for skill execution

Reference implementation mentioned: `plugin-cskills` (shared in Discord as the canonical pattern for capabilities + validation).

**Action for plugin/skill devs:** treat skills as untrusted input. Avoid loading arbitrary skill bundles without signature verification and/or a review pipeline.

## 2) New Features

### OAuth integration expansion (Eliza App / Cloud-facing)
OAuth integration work progressed significantly, with the following providers reported as implemented in the app chat stack:

- X.com
- GitHub
- Slack
- Linear

Next on deck: Notion; MCP testing planned after OAuth adapter work completes.

**Developer takeaway:** the OAuth architecture is now “integration-friendly” (adding providers is mostly credential + redirect URI plumbing). If you’re building a plugin that needs delegated access (e.g., reading Slack threads, writing Linear issues), expect the platform to standardize around OAuth-based connection objects rather than per-plugin token fields.

A typical high-level flow to align your plugin with this direction:

```ts
// Pseudocode: design your plugin to accept a resolved connection
type OAuthConnection = {
  provider: "github" | "slack" | "x" | "linear";
  accessToken: string;
  refreshToken?: string;
  expiresAt?: number;
};

export function createPlugin({ connection }: { connection: OAuthConnection }) {
  if (connection.provider !== "github") throw new Error("Wrong provider");
  // Use connection.accessToken for API calls; handle refresh if present.
}
```

Tracking issue context in core repo (roadmap items visible in Feb issues list):
- Billing (open): https://github.com/elizaos/eliza/issues/6448
- Character prompt iteration (open): https://github.com/elizaos/eliza/issues/6447

## 3) Bug Fixes

### elizacloud.ai: critical onboarding + account integrity bug (welcome email flow)
A high-severity production issue was reported affecting retention and data integrity:

- New accounts were **not receiving the promised $5 credit**
- Clicking **“get started”** in the welcome email could **overwrite an existing account + agents**
- The flow could create a **new account with $1** instead of applying credits to the intended user

**Technical interpretation (likely root causes):**
- Welcome email link likely encodes an **unsafe identifier** (e.g., a non-idempotent signup token) that triggers account creation rather than account association.
- Credit assignment appears **non-atomic** or attached to the wrong principal (email vs userId), causing mismatched balances.
- “Overwrite” strongly suggests an upsert keyed on something too broad (email) without guarding for existing authenticated sessions.

**Recommended remediation pattern (idempotent + safe):**
- Use a **single-use magic link token** that maps to a pending onboarding record.
- On click: require either (a) unauthenticated session that completes signup, or (b) authenticated session that *claims* the onboarding credit without account creation.
- Make credit grant **idempotent**:

```sql
-- Example: ensure credits are granted exactly once
INSERT INTO credit_grants (user_id, grant_key, amount_usd)
VALUES ($1, 'welcome_bonus_v1', 5)
ON CONFLICT (user_id, grant_key) DO NOTHING;
```

**Operational guidance from discussion:** pause welcome emails until the overwrite path is fixed.

### babylon.market: auth + rewards system regressions (hotfixed to production)
Multiple failures were debugged and a fix was merged to production during the week:

- Multiple **API endpoints failing**, breaking page flows
- **Username creation bug** producing `@userid:priv` instead of expected handle
- **Discord OAuth account linking** broken
- **Twitter follow reward claiming** failing with errors

Deployment coordination indicated the fix was pushed and subsequently confirmed merged to production by `tcm390`.

## 4) API Changes

### MCP plugin: dynamic tool actions (breaking line noted in recent activity)
While not merged into `elizaos/eliza` this week, the org’s MCP plugin had a recent breaking release noted in activity logs:

- `elizaos-plugins/plugin-mcp` **v1.8.0**: “feat!: Dynamic MCP tool actions”

If you depend on MCP tool invocation semantics, re-check how your agent enumerates and binds tool actions. Expect changes in action naming/registration and transport behavior (StreamableHTTP transport was also mentioned in nearby merged work).

(Repository reference: https://github.com/elizaos-plugins/plugin-mcp)

### Pending PR reviews (not enough public diff context in this dataset)
Two PRs were explicitly called out for review in Discord:
- elizaos/eliza PR #6457: https://github.com/elizaos/eliza/pull/6457
- elizaos/eliza-cloud-v2 PR #278: https://github.com/elizaos/eliza-cloud-v2/pull/278

If your work touches those areas, watch these PRs for interface changes once merged.

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

### Twitter
- Babylon rewards flow: “follow on Twitter” claim was broken and hotfixed server-side (platform-specific, but relevant if you use the same reward verification approach).
- Dev question remained open: *which Eliza version works properly with the Twitter plugin locally*. No definitive answer was posted.

**Practical guidance (until pinned officially):**
- Prefer a **known-good tag** for `@elizaos/cli` + plugin-twitter rather than `main`.
- If you are on a divergent core branch (e.g., `odi-dev` was recommended in earlier dev discussions), align plugin versions to the same commit-era to avoid runtime API mismatches.

Historical reference (broker auth added recently): https://github.com/elizaos-plugins/plugin-twitter/pull/47

### Discord
- Babylon.market: Discord OAuth linking was broken and targeted in the production fix.

### Farcaster
- Babylon.market had reported Farcaster login failures earlier in the week (still relevant for anyone embedding Farcaster auth into Eliza-adjacent products).

### Telegram
- No new Telegram plugin merges were recorded in this week’s provided GitHub activity, but Telegram remains a priority integration path (notably for “moltbot”-style deployments).

## 6) Model Provider Updates

### Anthropic: Claude Opus 4.6
Anthropic released **Claude Opus 4.6** (same price point as 4.5 per discussion), with reported improvements in:

- agentic coding
- tool use / computer use
- search
- finance reasoning

**Developer implication for ElizaOS agents:**
- If your agent relies on long-horizon tool plans (multi-step automations, repo maintenance agents, etc.), Opus 4.6 is a candidate upgrade where latency/cost tradeoffs are acceptable.
- Consider re-running evaluation suites for tool-call correctness (especially if you rely on strict JSON/tool schemas).

Provider docs (Anthropic): https://docs.anthropic.com/

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

### ElizaCloud V2: expect auth + billing surface changes
With active work happening in `eliza-cloud-v2` (PR #278 under review) and an open “Billing” issue in `elizaos/eliza` (#6448), developers should assume **billing identity, credit grants, and OAuth connection storage** may change shape between Cloud V1 and V2.

**Risk areas to audit in your integrations:**
- Any code that assumes “email == account identity”
- Non-idempotent onboarding flows (welcome emails, referral links, promo credits)
- Plugin configs that store raw provider tokens instead of referencing an OAuth connection object

### Token migration (AI16Z → ELIZAOS) operational impact
The 90-day token migration window closed; non-migrated tokens are reported as locked for one year. While not a code breaking change, it **does** affect developer support load and user trust/safety (scam attempts were reported in Discord).

**Recommendation:** if you run community-facing agents or support bots, add a safety skill / canned response that:
- directs users to official links only
- warns against DM-based “support”
- avoids requesting keys/seed phrases under any circumstances

---

## Relevant Links
- Discord threads (weekly source):
  - coders: https://discord.com/channels/1253563208833433701/1300025221834739744
  - core-devs: https://discord.com/channels/1253563208833433701/1377726087789940836
  - discussion: https://discord.com/channels/1253563208833433701/1253563209462448241
- PRs / Issues:
  - https://github.com/elizaos/eliza/pull/6457
  - https://github.com/elizaos/eliza-cloud-v2/pull/278
  - https://github.com/elizaos/eliza/issues/6448 (Billing)
  - https://github.com/elizaos/eliza/issues/6447 (Eliza character + prompt iteration)