# Issue Triage — 2026-04-24 (elizaOS)

## 1) Security/Brand: PR introduces malware-like autonomous shell agent (must not merge) — PR elizaos/eliza#6613 “feat(virus): add autonomous rust agent (concept art)”
- **Current Status:** Open PR (not merged); automated review flagged severe concerns (persistence + idle stealth + unrestricted shell execution).
- **Impact Assessment:**
  - **User Impact:** High (if merged/distributed, users who build/run artifacts are exposed to dangerous behavior)
  - **Functional Impact:** Partial (doesn’t break core runtime, but creates a high-risk official package)
  - **Brand Impact:** High (association with “virus/RAT” behavior can permanently harm trust)
- **Technical Classification:**
  - **Issue Category:** Security
  - **Component Affected:** Repo distribution / examples-packaging / safety posture
  - **Complexity:** Moderate effort (policy + repo hygiene + possible restructure), but decision is urgent
- **Resource Requirements:**
  - **Required Expertise:** Security review, OSS governance/maintainer judgment, release engineering
  - **Dependencies:** None (can act immediately)
  - **Estimated Effort:** 2 (to close/convert + add guardrails)
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Maintainer decision: **close PR** or request major rewrite moving it to an external repo (not under elizaOS org) with explicit safety disclaimers.
  2. Add/clarify contribution policy: disallow persistence/stealth/autonomous shell exec examples in official repos.
  3. Add CI guardrails: block packages named `virus` / detect registry persistence calls / “LLM-to-shell” patterns without explicit sandboxing.
  4. If an “autonomous local agent” example is desired, redesign around **capability gating** (explicit allowlists, no persistence, no stealth triggers, no arbitrary shell).
- **Potential Assignees:** odilitime (core maintainer/release), lalalune (stability/infra), ai16z-demirix (security reporter track record)

---

## 2) CI/CD: Registry PR workflow failing due to missing OIDC permissions — PR elizaos-plugins/registry#346
- **Current Status:** Failing CI (`claude-code-action` cannot fetch OIDC token; missing `id-token: write` or token permissions).
- **Impact Assessment:**
  - **User Impact:** Medium (plugin submissions/merges blocked; ecosystem velocity reduced)
  - **Functional Impact:** Partial (doesn’t break runtime, but blocks registry contributions)
  - **Brand Impact:** Medium (public CI failures reduce confidence in maintenance)
- **Technical Classification:**
  - **Issue Category:** Bug (CI/DevEx)
  - **Component Affected:** Plugin Registry / GitHub Actions workflow permissions
  - **Complexity:** Simple fix
- **Resource Requirements:**
  - **Required Expertise:** GitHub Actions, OIDC permissions, repo admin access
  - **Dependencies:** Requires maintainer/admin to adjust workflow/repo settings
  - **Estimated Effort:** 1
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Update workflow YAML: set `permissions: id-token: write` (and minimally scoped `contents: read`) for the job using OIDC.
  2. Confirm the action uses `github_token` vs custom token; ensure `GITHUB_TOKEN` permissions match org policy.
  3. Re-run CI on #346; validate other PRs are unblocked.
  4. Add a short “CI permissions” section to registry CONTRIBUTING to prevent recurrence.
- **Potential Assignees:** odilitime (repo admin), igor.peregudov (reported), stan0473 (CI context)

---

## 3) Privacy/Security: Implement data-sanitization layer before model calls — Issue elizaos/eliza#7007 “data-sanitization layer to protect user privacy”
- **Current Status:** Open initiative (called out in weekly summary as a new strategic initiative).
- **Impact Assessment:**
  - **User Impact:** High (PII leakage risk affects all deployments that pass user data to models)
  - **Functional Impact:** Partial (core works, but unsafe by default without sanitization)
  - **Brand Impact:** High (privacy posture is central for agent frameworks)
- **Technical Classification:**
  - **Issue Category:** Security
  - **Component Affected:** Core Framework (prompt assembly/providers), Model Integration, Memory/Logging
  - **Complexity:** Architectural change
- **Resource Requirements:**
  - **Required Expertise:** Security engineering, prompt/runtime internals, data governance
  - **Dependencies:** Needs alignment with logging controls + plugin surfaces (e.g., attachments/providers)
  - **Estimated Effort:** 5
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Define threat model + scope: PII classes, secrets, credentials, wallet keys, OAuth tokens, receipts.
  2. Implement sanitization pipeline hook at a single choke point (pre-model, pre-logging, pre-provider enrichment).
  3. Add redaction policies + tests (unit + golden prompt tests).
  4. Provide extension points for plugins (plugin can register its own sanitizer).
  5. Document defaults + “strict mode” (fail closed vs best-effort redaction).
- **Potential Assignees:** odilitime (core runtime), lalalune (runtime/message service), ai16z-demirix (security validation)

---

## 4) Release/Compatibility: v2 “alpha” stability and stable release plan needed (unblocks builders) — (Tracking item; GitHub issue/ID not provided)
- **Current Status:** Community asking for stable timing; v2 considered “ready for development” but still labeled alpha; many dependency upgrades in flight.
- **Impact Assessment:**
  - **User Impact:** High (builders need a stable target for production agents/plugins)
  - **Functional Impact:** Partial (works, but version churn/alpha label increases breakage risk)
  - **Brand Impact:** Medium (stability messaging + release hygiene)
- **Technical Classification:**
  - **Issue Category:** Bug/Release Engineering (process + stabilization)
  - **Component Affected:** Core Framework, CLI, Plugin System, CI/Release pipelines
  - **Complexity:** Complex solution (stabilization across multiple packages)
- **Resource Requirements:**
  - **Required Expertise:** Release engineering, TypeScript/Bun tooling, CI workflows
  - **Dependencies:** Open dependency PRs; release automation health; final blocker triage
  - **Estimated Effort:** 4
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Create a “v2 stable” tracking issue (single source of truth) listing blockers: CI green, docs, migration notes, plugin compatibility matrix.
  2. Cut a release candidate branch; freeze non-critical dependency bumps until RC passes.
  3. Publish explicit semver policy and deprecation window for plugin authors.
  4. Ship a stability checklist: install, build, basic agent run, plugin load, streaming, memory adapters.
- **Potential Assignees:** odilitime (release), lalalune (stability), NubsCarson (bugfix focus)

---

## 5) Community Ops/Platform: Discord posts auto-deleted with no audit logs — (Discord incident; ID not provided)
- **Current Status:** Ongoing/observed; moderators unable to find cause; manual reposting done.
- **Impact Assessment:**
  - **User Impact:** Medium (contributors lose messages; support + coordination degraded)
  - **Functional Impact:** No (not runtime), but blocks collaboration
  - **Brand Impact:** Medium (appears chaotic/unreliable, amplifies transition concerns)
- **Technical Classification:**
  - **Issue Category:** UX / Operations
  - **Component Affected:** Discord moderation tooling / integrations
  - **Complexity:** Moderate effort (investigation across Discord settings/bots/webhooks)
- **Resource Requirements:**
  - **Required Expertise:** Discord admin/mod tooling, bot/webhook debugging
  - **Dependencies:** Audit bot list, permissions, AutoMod, message filters, 3rd-party integrations
  - **Estimated Effort:** 3
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Inventory bots/webhooks and recent permission changes; temporarily disable non-essential bots.
  2. Review AutoMod rules, flagged keywords/links, and any “anti-spam” services.
  3. Enable additional logging (if available) and create a repro checklist (content type, channel, link presence).
  4. Publish a short incident note + workaround (e.g., pastebin for long posts; ask users to DM mods if deleted).
- **Potential Assignees:** odilitime (Community Ops/mod), dankvr (moderation/core dev)

---

## 6) Brand/Comms Risk: Lack of official comms during lawsuit; X account inactive; delisting concern — (Tracking item; ID not provided)
- **Current Status:** Community frustration; legal counsel advising reduced comms; concern about exchange delistings.
- **Impact Assessment:**
  - **User Impact:** High (token holders + builders uncertain; drives churn)
  - **Functional Impact:** No (code runs), but adoption/support suffers
  - **Brand Impact:** High (silence interpreted negatively)
- **Technical Classification:**
  - **Issue Category:** Documentation / UX (project communication), Governance
  - **Component Affected:** Public channels (X, website, Discord announcements)
  - **Complexity:** Moderate effort (legal-safe messaging + access management)
- **Resource Requirements:**
  - **Required Expertise:** Community ops, legal coordination, crisis comms
  - **Dependencies:** Access to official accounts; legal review pipeline
  - **Estimated Effort:** 2
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Draft a legally safe “status + continuity” statement (what can be said, what cannot).
  2. Establish a minimum cadence (weekly) for: shipping updates, governance notes, security warnings.
  3. Restore/transfer access to X/website to designated stewards with 2FA + shared ops runbook.
  4. Create an “Exchanges & Partners” contact playbook (proactive reassurance without legal exposure).
- **Potential Assignees:** odilitime (Community Ops), quanteliza (process proposal), valleybeyond7991 (social support)

---

## 7) Ecosystem Migration: Port “elisym” to v3 after merge into elizaOS ecosystem — (Tracking item; ID not provided)
- **Current Status:** Identified as “next quest” after merge; feasibility discussed; needs execution plan.
- **Impact Assessment:**
  - **User Impact:** Medium (users of elisym need compatibility)
  - **Functional Impact:** Partial (blocks specific plugin/app functionality on v3)
  - **Brand Impact:** Low/Medium (ecosystem coherence)
- **Technical Classification:**
  - **Issue Category:** Feature / Maintenance
  - **Component Affected:** Plugin System / Version compatibility (v2→v3)
  - **Complexity:** Complex solution (API changes + testing)
- **Resource Requirements:**
  - **Required Expertise:** Plugin APIs, version migration, TypeScript
  - **Dependencies:** v3 API stability; docs for migration targets
  - **Estimated Effort:** 4
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Create migration checklist: breaking API deltas, required adapters, test harness.
  2. Build a compatibility layer (if feasible) or release elisym v3-native package.
  3. Add CI matrix tests against latest v3.
- **Potential Assignees:** stan0473 (identified work), igor.peregudov (feasibility), odilitime (integration oversight)

---

## 8) Payments/Plugins: Ship + document LemonCake payment plugin integration (M2M payments, spend-capped tokens) — Plugin: `eliza-plugin-lemoncake` (GitHub issue/ID not provided)
- **Current Status:** Open-source plugin announced; “one line” integration claim; implementation approved; needs official docs + example.
- **Impact Assessment:**
  - **User Impact:** Medium (builders needing paywalls/M2M payments)
  - **Functional Impact:** No (optional capability), but unlocks important agent commerce use cases
  - **Brand Impact:** Medium (professionalism of plugin ecosystem; security expectations)
- **Technical Classification:**
  - **Issue Category:** Feature + Documentation
  - **Component Affected:** Plugin System, Commerce integrations
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** Plugin authoring, security review (token spend caps), docs
  - **Dependencies:** Decide official stance on payment rails + risk disclosures (USDC freezing, revocation model)
  - **Estimated Effort:** 3
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Add an official guide page: install, configure, sandbox mode, receipts/idempotency.
  2. Provide a minimal example agent demonstrating: capped spend token issuance → API call → receipt logging.
  3. Security checklist for commerce plugins (revocation, auditing, least privilege).
- **Potential Assignees:** lemoncake03027 (implementation), odilitime (ecosystem approval/docs merge), itssowenn4462 (new contributor; could help with docs/examples)

---

## 9) Support/Policy: Late AI16Z→ELIZAOS token migration requests (waitlist) — (Process item; ID not provided)
- **Current Status:** Migration window closed; ad-hoc waitlist offered; users discovering too late.
- **Impact Assessment:**
  - **User Impact:** Medium (subset of token holders; high emotional impact)
  - **Functional Impact:** No (not core runtime)
  - **Brand Impact:** Medium/High (trust + perceived fairness)
- **Technical Classification:**
  - **Issue Category:** UX / Documentation / Governance
  - **Component Affected:** Migration support operations
  - **Complexity:** Moderate effort (policy + tooling + comms)
- **Resource Requirements:**
  - **Required Expertise:** Community ops, token tooling/admin, documentation
  - **Dependencies:** On-chain/contract constraints; legal/compliance considerations
  - **Estimated Effort:** 2
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Publish a clear policy: whether late migrations are possible, criteria, deadlines, and “no guarantees” language.
  2. Create a simple intake form + tracking sheet (reduce Discord DMs).
  3. Add anti-phishing warnings on migration docs (tie-in with recent drainer incident).
- **Potential Assignees:** odilitime (Migration Support role), pmairca (Migration Support), Community Ops helpers

---

## 10) Research/Interop: Decentralized private state verification for agents via local ZK proofs — (New issue mentioned; ID not provided)
- **Current Status:** Newly raised; no implementation plan in provided data.
- **Impact Assessment:**
  - **User Impact:** Low/Medium (advanced users; long-term differentiator)
  - **Functional Impact:** No (not blocking current features)
  - **Brand Impact:** Medium (thought leadership if executed; risk if promised prematurely)
- **Technical Classification:**
  - **Issue Category:** Feature Request / Architectural initiative
  - **Component Affected:** Core Framework (agent interoperability), Security/Trust layer
  - **Complexity:** Architectural change
- **Resource Requirements:**
  - **Required Expertise:** Applied cryptography, ZK systems engineering, protocol design
  - **Dependencies:** Clear interoperability spec; threat model; performance constraints
  - **Estimated Effort:** 5
- **Recommended Priority:** **P3**
- **Specific Actionable Next Steps:**
  1. Convert into an RFC with concrete use cases (state attestation, capability proofs, reputation).
  2. Compare approaches: zk-SNARKs vs zk-STARKs vs TEEs; define minimal viable “proof of state hash”.
  3. Identify integration points in runtime (state snapshots, receipts, verification endpoints).
- **Potential Assignees:** odilitime (architecture), external contributors with ZK expertise (to be recruited)

---

# Top Priority Summary (next 5–10 items to act on)

1. **P0:** Block/close **elizaos/eliza#6613** (malware-like “virus” PR) and add policy/CI guardrails.  
2. **P0:** Fix GitHub Actions OIDC permissions breaking **elizaos-plugins/registry#346** workflow.  
3. **P0:** Drive **elizaos/eliza#7007** data-sanitization layer (privacy baseline).  
4. **P1:** Create and execute a **v2 stable release plan** (tracking issue + RC + freeze).  
5. **P1:** Investigate/resolve **Discord silent auto-deletions** to restore contributor trust.  
6. **P1:** Publish **legal-safe project comms cadence** (reduce delisting/abandonment narrative).  
7. **P2:** Port **elisym → v3** with a defined migration checklist and CI coverage.  
8. **P2:** Ship official docs/examples for **LemonCake payment plugin**; add commerce security checklist.  
9. **P2:** Standardize **late token migration** intake + documentation + anti-phishing warnings.  
10. **P3:** Convert ZK private state verification into an RFC (avoid premature commitments).

---

# Patterns / Themes Indicating Deeper Issues

- **Security posture gaps at repo boundaries:** High-risk code can enter via “concept art” PRs; need stronger governance and automated safety checks.
- **Release/process strain from high churn:** Many dependency upgrades and broad refactors increase instability perception; stable release signaling lags behind readiness claims.
- **Single-point-of-failure in ops access:** Limited access to official accounts + legal constraints creates communication vacuums and fuels reputational damage.
- **Ecosystem growth vs. quality control:** Plugin registry velocity is high, but CI and documentation must keep up to prevent integrator frustration.

---

# Process Improvement Recommendations

1. **Security intake gate for risky contributions:** Add a “Security/Abuse potential” checklist in PR template; require maintainer sign-off for persistence, shell execution, wallet/key handling, or stealth automation.
2. **Establish release trains:** Fixed cadence (weekly alpha, monthly stable/RC) with a published compatibility matrix for core + key plugins.
3. **Operational runbooks + delegated access:** Formalize account access (X/website/CI secrets) with named stewards, rotation plan, and minimal comms cadence even under legal constraints.
4. **Incident tracking for community platforms:** Treat Discord outages/deletions like incidents (timestamped logs, owner, mitigation, postmortem).
5. **Docs-as-a-feature for plugins:** Require minimal integration docs + example agent + security notes before featuring payment/commerce plugins in official channels.