## Issue Triage — 2026-04-22

### 1) CI failing: `claude-code-action` can’t fetch OIDC token (missing workflow permissions) — **elizaos-plugins/registry PR #346**
- **Current Status:** Open PR blocked; CI failing due to repo/workflow config (not code).
- **Impact Assessment:**
  - **User Impact:** Medium (blocks ecosystem plugin additions; affects contributors)
  - **Functional Impact:** Partial (blocks registry PR throughput / releases)
  - **Brand Impact:** Medium (public CI failures reduce confidence)
- **Technical Classification:**
  - **Issue Category:** Bug / Infrastructure
  - **Component Affected:** CI/CD, Plugin Registry
  - **Complexity:** Simple fix
- **Resource Requirements:**
  - **Required Expertise:** GitHub Actions, OIDC/permissions model
  - **Dependencies:** Requires repo admin/maintainer permissions on `elizaos-plugins/registry`
  - **Estimated Effort (1–5):** 1
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Update workflow permissions to include `id-token: write` (and verify `contents: read` / correct `github_token` usage).
  2. Confirm `claude-code-action` is configured to use OIDC (not a missing secret) and that the job has the correct `permissions:` block.
  3. Re-run CI on PR #346; verify successful token acquisition and job completion.
  4. Add a short “CI OIDC requirements” note to registry CONTRIBUTING / workflow README to prevent recurrence.
- **Potential Assignees:** **odilitime** (core dev/admin), **stan0473** (core dev), **lalalune** (CI/release stabilization history)

---

### 2) High-risk/malware-like package proposal in core repo — **elizaos/eliza PR #6613 “feat(virus): add autonomous rust agent (concept art)”**
- **Current Status:** Open PR; security review flags RAT-like behaviors (persistence, stealth activation, unrestricted shell exec).
- **Impact Assessment:**
  - **User Impact:** Critical (could lead to real-world harm if merged/distributed)
  - **Functional Impact:** Yes (introduces an unsafe execution surface under elizaOS brand)
  - **Brand Impact:** High (association with malware behaviors is reputationally severe)
- **Technical Classification:**
  - **Issue Category:** **Security**
  - **Component Affected:** Core repo distribution / packages, Rust agent tooling
  - **Complexity:** Moderate (decision + removal/containment; not a “bug fix”)
- **Resource Requirements:**
  - **Required Expertise:** Security engineering, release governance, supply-chain risk
  - **Dependencies:** None; can be acted on immediately (policy decision)
  - **Estimated Effort (1–5):** 2
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Immediately label PR with `security-risk`, `do-not-merge`, and request changes/closure.
  2. Decide policy: disallow persistence + unrestricted shell execution packages in official monorepo; document in SECURITY / contributing guidelines.
  3. If keeping as research: move to an external, clearly separated repo under a different namespace and add explicit warnings; ensure it is not built/published by default.
  4. Audit current release pipelines to ensure no accidental packaging of `packages/virus` artifacts.
- **Potential Assignees:** **odilitime** (repo governance), **ai16z-demirix** (security reporter background), **lalalune** (release/CI controls), **satsbased** (maintainer oversight)

---

### 3) Community security: recurring Discord phishing/scam activity (airdrops, fake support tickets)
- **Current Status:** Active/recurring; moderators banning accounts; users still getting scammed.
- **Impact Assessment:**
  - **User Impact:** High (direct financial loss reported; ongoing impersonation)
  - **Functional Impact:** Partial (community support channels become unsafe/noisy)
  - **Brand Impact:** High (users associate scams with project/community)
- **Technical Classification:**
  - **Issue Category:** Security / UX (community operations)
  - **Component Affected:** Discord community ops, support workflow
  - **Complexity:** Moderate (process + automation + education)
- **Resource Requirements:**
  - **Required Expertise:** Discord moderation, anti-phishing ops, automation/bots
  - **Dependencies:** Potentially depends on Discord role/channel permission adjustments and bot configuration
  - **Estimated Effort (1–5):** 3
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Lock down high-risk surfaces: restrict link posting for new accounts; add stricter AutoMod rules for “airdrop”, “support ticket”, URL shorteners.
  2. Create an “Official Support” pinned message with canonical links; clarify “no DMs from staff; no airdrops in Discord.”
  3. Add a simple reporting flow: a dedicated channel/form + bot command to report suspicious users/links.
  4. Consider shipping/using the proposed “scammer detection/plugin” only if it is clearly scoped, privacy-safe, and doesn’t create harassment risk.
- **Potential Assignees:** **shawmakesmagic** (moderation), **odilitime** (community ops/mod), **stan0473** (plugin idea coordination)

---

### 4) Request/need: PII sanitization layer for logs/memories (newly raised; details referenced in dev log)
- **Current Status:** Newly raised (referenced in development logs); prior PII sanitization items reported as closed “across multiple repos,” but a new request indicates gaps remain.
- **Impact Assessment:**
  - **User Impact:** High (risk of leaking user secrets/PII via logs, memory stores, providers)
  - **Functional Impact:** Partial (not always blocking runtime, but affects safe deployment)
  - **Brand Impact:** High (privacy failures are trust-damaging)
- **Technical Classification:**
  - **Issue Category:** Security
  - **Component Affected:** Core Framework (runtime logging, memory persistence), Agent apps (LifeOps), Plugin System
  - **Complexity:** Complex solution (cross-cutting)
- **Resource Requirements:**
  - **Required Expertise:** Security/privacy engineering, data handling, redaction/tokenization, threat modeling
  - **Dependencies:** Needs agreement on data classification + integration points (logger, memory adapters, provider outputs)
  - **Estimated Effort (1–5):** 5
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Convert the request into a concrete GitHub issue (if not already) with explicit scope: **where PII can enter** (prompts, provider payloads, memory, logs) and **where it can leak** (stdout, file logs, telemetry, Discord plugins).
  2. Define minimal viable controls: configurable redaction rules + “safe logger” wrapper + opt-out/opt-in per environment.
  3. Add test fixtures to ensure common secrets (API keys, mnemonics, emails, phone numbers) are redacted before persistence/output.
  4. Ensure LifeOps + cloud auth flows never log tokens (including refresh paths).
- **Potential Assignees:** **odilitime** (core architecture), **0xSolace** (core changes volume/experience), **lalalune** (runtime/reliability), **ai16z-demirix** (security validation)

---

### 5) Auth reliability: “silent logout” and multi-provider wallet/GitHub auth styling inconsistencies (cloud/app-core)
- **Current Status:** Mitigations shipped per dev log (server-side Steward token refresh; UI fixes in React package). Needs verification + regression coverage.
- **Impact Assessment:**
  - **User Impact:** Medium–High (auth instability directly degrades UX; blocks usage for some)
  - **Functional Impact:** Partial (core usage flows depend on auth)
  - **Brand Impact:** Medium (feels “unstable” to end users)
- **Technical Classification:**
  - **Issue Category:** Bug / UX
  - **Component Affected:** Cloud/Auth, GUI (React package / app-core)
  - **Complexity:** Moderate effort (end-to-end testing + edge cases)
- **Resource Requirements:**
  - **Required Expertise:** Web auth, session refresh, React UI, wallet providers (EVM/Solana)
  - **Dependencies:** Ongoing “authorize flow migration to Steward” (WIP in dev log)
  - **Estimated Effort (1–5):** 3
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Add an end-to-end test covering token refresh + tab-idle + return flow (the “silent logout” reproduction).
  2. Verify both wallet and GitHub logins behave consistently across staging/prod.
  3. Ensure UI fixes for provider buttons are applied across all surfaces (no regressions in responsive layouts / text wrapping).
- **Potential Assignees:** **odilitime**, **lalalune**, **0xSolace**

---

### 6) Model compatibility: inconsistent output formatting across models; adoption of `PROMPT_OUTPUT_FORMAT` env var — **elizaos/eliza PR #6978 (feature)**
- **Current Status:** Implemented per logs (new env var to improve compatibility with Gemini 2.5 Pro and Llama/Ollama). Needs rollout discipline and docs alignment.
- **Impact Assessment:**
  - **User Impact:** Medium (affects users running non-Claude models; reduces prompt parsing failures)
  - **Functional Impact:** Partial (format mismatch can break tool/action loops)
  - **Brand Impact:** Medium (model “compatibility” is a quality signal)
- **Technical Classification:**
  - **Issue Category:** Bug / Feature (compatibility hardening)
  - **Component Affected:** Core Framework (runtime prompt execution), Model Integration
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** Prompting/runtime parsing, model behavior differences, docs
  - **Dependencies:** Requires docs + example configs to drive correct usage
  - **Estimated Effort (1–5):** 2
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Document recommended values and when to use them (Claude vs Gemini vs Llama/Ollama).
  2. Update examples to set `PROMPT_OUTPUT_FORMAT` for non-Claude model presets.
  3. Add a “detect + warn” startup log when model/provider is known to be incompatible with default format.
- **Potential Assignees:** **lalalune**, **NubsCarson** (model stability focus), **odilitime**

---

### 7) Data consistency parity: InMemory DB adapter ordering & room migration behaviors — **elizaos/eliza PRs #7000 / #6965**
- **Current Status:** Fixes in flight/completed in recent work (descending sort to match plugin-sql; roomId update correctness).
- **Impact Assessment:**
  - **User Impact:** Medium (inconsistent memory ordering breaks “recent context,” compaction, and testing)
  - **Functional Impact:** Partial (affects agent behavior, especially in dev/local mode)
  - **Brand Impact:** Medium (non-determinism = perceived instability)
- **Technical Classification:**
  - **Issue Category:** Bug
  - **Component Affected:** Core Framework (Database adapters, Memory)
  - **Complexity:** Simple–Moderate
- **Resource Requirements:**
  - **Required Expertise:** TypeScript, memory store semantics, test reliability
  - **Dependencies:** Ensure alignment with plugin-sql semantics and any compaction logic
  - **Estimated Effort (1–5):** 2
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Confirm both fixes land with coverage: ordering + room migration + compaction tests.
  2. Add a small “adapter parity contract” test suite shared by adapters (in-memory vs sql) to prevent drift.
- **Potential Assignees:** **avasis-ai** (roomId fix author), **0xSolace**, **lalalune**

---

### 8) Unresolved provider request: MiniMax “token plan key” integration as a provider plugin (Discord request)
- **Current Status:** Unresolved request; no linked GitHub issue/PR in provided data.
- **Impact Assessment:**
  - **User Impact:** Low–Medium (depends on how many users rely on MiniMax)
  - **Functional Impact:** No (not core; provider expansion)
  - **Brand Impact:** Low
- **Technical Classification:**
  - **Issue Category:** Feature Request
  - **Component Affected:** Model Integration / Plugin System
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** Provider plugin authoring, MiniMax API/auth model, secrets handling
  - **Dependencies:** Needs a tracked GitHub issue + API constraints clarity
  - **Estimated Effort (1–5):** 3
- **Recommended Priority:** **P3**
- **Specific Actionable Next Steps:**
  1. Create a GitHub issue capturing requirements (auth method, rate limits, supported endpoints, config).
  2. Decide whether it belongs in core providers or as a community plugin.
- **Potential Assignees:** **stan0473** (plugin ecosystem), **NubsCarson** (model integration), community contributor requesting it (if identified)

---

## Conclusion

### 1) Top 5–10 highest priority issues to address immediately
1. **P0:** Fix registry CI OIDC permissions blocking PRs — **elizaos-plugins/registry PR #346**
2. **P0:** Prevent merging/distributing malware-like “virus” package — **elizaos/eliza PR #6613**
3. **P0:** Discord phishing/scam mitigation hardening (AutoMod + link restrictions + official support guidance)
4. **P1:** Implement/standardize **PII sanitization layer** across logging/memory boundaries
5. **P1:** Verify auth stability fixes (token refresh / silent logout) + add regression tests
6. **P2:** Roll out and document `PROMPT_OUTPUT_FORMAT` to reduce model/tool-loop failures
7. **P2:** Ensure memory adapter parity fixes land (ordering + roomId migration) with contract tests
8. **P3:** Triage MiniMax provider integration request into a tracked issue and scope it

### 2) Patterns/themes indicating deeper architectural problems
- **Cross-cutting security gaps:** Community-level scams + code-level privacy/sanitization needs indicate missing “security-by-default” posture across product + ops.
- **Workflow/config fragility:** CI failures caused by missing permissions suggest insufficient “config change validation” and lack of documented requirements for reusable actions (OIDC).
- **Ecosystem scaling pains:** Rapid plugin registry growth increases operational load; failures in registry CI become a bottleneck for the whole ecosystem.

### 3) Recommendations for process improvements
- **Introduce a “Security Gate” checklist for PRs** (especially new packages/tools): persistence, shell execution, credential handling, logging/PII, network calls.
- **Codify GitHub Actions baselines**: standard reusable workflow templates with required `permissions:` blocks; add a CI job that lints workflows for missing OIDC permissions where needed.
- **Centralize incident response messaging**: pinned “official support” policy, anti-scam automation, and a repeatable moderator playbook (with escalation paths).
- **Add adapter parity contract tests** to prevent behavioral drift between in-memory and SQL memory stores as features evolve.