## Issue Triage — 2026-02-16 (elizaOS)

### 1) Active Discord Scams via “coders” Threads (ban + lock down thread creation) — ID: DISCORD-SEC-2026-02-15-THREAD-SCAMS
- **Current Status:** Reported active; at least one scammer identified (ID `364718078946312192`). No confirmation of ban/permission changes completed.
- **Impact Assessment:**
  - **User Impact:** **Critical** (users being socially engineered; potential fund loss)
  - **Functional Impact:** **Partial** (blocks safe support/onboarding; drives users away)
  - **Brand Impact:** **High** (public trust damage; “project is unsafe” narrative)
- **Technical Classification:**
  - **Issue Category:** **Security / UX (Community Safety)**
  - **Component Affected:** **Discord Ops / Community Support**
  - **Complexity:** **Simple fix** (permissions + moderation), **Moderate** (process hardening)
- **Resource Requirements:**
  - **Required Expertise:** Discord admin/moderation, security incident handling, community comms
  - **Dependencies:** None (can act immediately)
  - **Estimated Effort (1–5):** **2**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. **Immediately ban** Discord user ID `364718078946312192` and remove any active scam threads.
  2. **Restrict thread creation** in high-risk channels (e.g., coders) to trusted roles; audit all channels where “support-like” threads can be created.
  3. Post a **pinned, templated security warning**: “No official support will ask you to join other servers/Zoom or share keys; only support links are X/Y.”
  4. Create an **official support intake policy**: where users go, what staff accounts look like, how to verify.
  5. Add lightweight **incident logging** (who banned, when, what links were used) for future postmortems.
- **Potential Assignees:** Omid Sa (admin decisions), Odilitime (community security guidance), Monsgroow (reporting/mod help), Stan ⚡ (ops follow-through)


### 2) Image Content Stripped from LLM Requests in Cloud Chat — GitHub: elizaos/eliza **#6494**
- **Current Status:** **Open**; identified location: `/api/v1/chat/completions` and `convertToUIMessages`.
- **Impact Assessment:**
  - **User Impact:** **High** (cloud chat multimodal broken for any user sending images)
  - **Functional Impact:** **Yes** (breaks core “chat with images” capability)
  - **Brand Impact:** **High** (perceived as “doesn’t support images / unreliable API”)
- **Technical Classification:**
  - **Issue Category:** **Bug**
  - **Component Affected:** **API / Cloud Chat message conversion pipeline**
  - **Complexity:** **Moderate effort** (message schema + conversion + regression tests)
- **Resource Requirements:**
  - **Required Expertise:** TypeScript server/API, message formatting for multimodal LLMs, SSE/streaming familiarity
  - **Dependencies:** None strictly, but align with any ongoing message schema refactors
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Add a minimal **repro fixture** (request payload containing image parts) and snapshot the outgoing provider payload.
  2. Audit `convertToUIMessages` for dropped fields (e.g., `content` arrays, `image_url`, attachments mapping).
  3. Confirm provider adapters (OpenAI-compatible, etc.) receive correct multimodal format.
  4. Add **unit test**: “image in → preserved in provider request”; add **integration test** hitting `/api/v1/chat/completions`.
  5. Verify cloud UI renders and sends the correct structure (ensure bug isn’t client-side serialization).
- **Potential Assignees:** borisudovicic (reporter; cloud/API context), lalalune (core runtime/message pipeline), anchapin (defensive correctness + tests)


### 3) URL in Message Triggers Duplicate LLM Calls (Processed as Text + Attachment) — GitHub: elizaos/eliza **#6486**
- **Current Status:** **Open**; affects webapp; duplicates streamed responses and doubles token usage.
- **Impact Assessment:**
  - **User Impact:** **High** (common workflow: users paste links frequently)
  - **Functional Impact:** **Partial** (responses still produced, but duplicated + cost spike)
  - **Brand Impact:** **High** (“wastes tokens”, “buggy streaming”, “untrustworthy costs”)
- **Technical Classification:**
  - **Issue Category:** **Bug / Performance**
  - **Component Affected:** **Webapp + message ingestion + attachments/preview pipeline + SSE stream assembly**
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Client/server message pipeline, SSE streaming, URL preview/metadata handling
  - **Dependencies:** Potentially related to attachment parsing rules and any link-preview feature
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Instrument logs to confirm **two LLM invocations** (trace IDs) for one user message containing a URL.
  2. Identify the decision point where URL preview becomes an “attachment” and ensure it doesn’t create a second “message to process”.
  3. Define canonical behavior: **either** (a) treat as plain text with inline URL, **or** (b) extract URL preview but **do not** trigger a second completion.
  4. Add regression test: one message with URL → **exactly one** completion and one streamed response.
  5. If needed, add a dedupe guard: same message ID + same run ID cannot spawn another completion.
- **Potential Assignees:** lalalune (core runtime + streaming), anchapin (bugfix patterns + guards), thewoweffect (reporter for validation)


### 4) Discord “Support Ticket” Impersonation Vector (fake tickets) — ID: DISCORD-SEC-2026-02-15-FAKE-TICKETS
- **Current Status:** Active attempts observed; at least one user engaged for ~2 days before detection.
- **Impact Assessment:**
  - **User Impact:** **Critical**
  - **Functional Impact:** **Partial** (support channel becomes dangerous)
  - **Brand Impact:** **High**
- **Technical Classification:**
  - **Issue Category:** **Security**
  - **Component Affected:** **Community Support Workflow**
  - **Complexity:** **Moderate effort** (policy + bot automation recommended)
- **Resource Requirements:**
  - **Required Expertise:** Discord automation/bots, incident response, comms
  - **Dependencies:** Agreement on “official support” endpoints
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Implement an **official support bot** or locked support channel with only staff-created threads.
  2. Add an **auto-moderation rule**: delete messages containing “open a ticket here” + external server invites in support contexts.
  3. Publish “How to verify staff” guidance and require staff to use a consistent role + naming convention.
- **Potential Assignees:** Omid Sa (policy/permissions), Stan ⚡ (ops), Odilitime (community safety messaging)


### 5) Token Migration Deadline Fallout (missed migration, no recourse) — ID: DISCORD-PROD-2026-02-15-MIGRATION-FALLOUT
- **Current Status:** Ongoing community distress; official stance communicated as “closed, no further support.”
- **Impact Assessment:**
  - **User Impact:** **High** (multiple long-term holders affected; likely more silent churn)
  - **Functional Impact:** **No** (not framework functionality)
  - **Brand Impact:** **High** (reputation + community cohesion; “punishes holders” narrative)
- **Technical Classification:**
  - **Issue Category:** **UX / Documentation / Process**
  - **Component Affected:** **Community Operations / Token Support**
  - **Complexity:** **Architectural change (process/policy)** if reopened; otherwise **Simple** to improve comms
- **Resource Requirements:**
  - **Required Expertise:** Community management, legal/compliance awareness, on-chain verification, comms
  - **Dependencies:** Leadership decision (whether any remediation is allowed)
  - **Estimated Effort (1–5):** **2** (comms), **4** (if remediation mechanism is approved)
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Publish a **final canonical post**: dates, ratio (1:6), what “ticket submitted before deadline” means, and clear rationale.
  2. Add a **migration postmortem**: what went wrong in comms, what will change next time.
  3. If leadership allows: define a **narrow remediation policy** (e.g., one-time appeals with strict on-chain proof + anti-fraud checks) and a hard end date.
  4. Add an email/newsletter opt-in (or equivalent) specifically for **time-sensitive actions**.
- **Potential Assignees:** Omid Sa (final policy), Biazs (support messaging consistency), DorianD (investor comms systems), Stan ⚡ (ops execution)


### 6) Base Install Should Prompt Agents About ElizaCloud Capabilities (discoverability) — ID: DISCORD-FEAT-2026-02-15-ELIZACLOUD-AWARENESS
- **Current Status:** Proposed by community; not tracked as a GitHub issue in provided data.
- **Impact Assessment:**
  - **User Impact:** **Medium** (improves onboarding + feature discovery)
  - **Functional Impact:** **Partial** (doesn’t fix broken behavior; improves default usefulness)
  - **Brand Impact:** **Medium** (more coherent product experience)
- **Technical Classification:**
  - **Issue Category:** **UX / Feature Request**
  - **Component Affected:** **Core Framework defaults / Base install templates / System prompts**
  - **Complexity:** **Moderate effort** (prompt design + template changes + docs)
- **Resource Requirements:**
  - **Required Expertise:** Prompt engineering, product onboarding, template/tooling in CLI
  - **Dependencies:** Alignment with Cloud integration direction (e.g., PR #6216 concept)
  - **Estimated Effort (1–5):** **2**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Convert into a GitHub issue with acceptance criteria: where the prompt lives, how it’s toggled, and how it avoids vendor-lock feel.
  2. Implement in starter templates: a small “capabilities discovery” system message + optional banner in CLI.
  3. Add docs: “When to use ElizaCloud vs local storage” and security boundaries.
- **Potential Assignees:** lalalune (install/bootstrap templates), DorianD (product framing), borisudovicic (cloud UX), Odilitime (prompt iteration)


### 7) Support Custom OpenAI Endpoint URL for OpenAI Provider — GitHub: elizaos/eliza **#6490**
- **Current Status:** **Open**; blocks OpenAI-compatible providers requiring custom base URL (e.g., SiliconFlow).
- **Impact Assessment:**
  - **User Impact:** **Medium** (affects users on alternative inference providers)
  - **Functional Impact:** **Partial** (core works with OpenAI, but reduces portability)
  - **Brand Impact:** **Medium** (integration flexibility expectation in agent frameworks)
- **Technical Classification:**
  - **Issue Category:** **Feature Request**
  - **Component Affected:** **Model Integration / Provider configuration**
  - **Complexity:** **Simple fix** to **Moderate effort** (config plumbing + validation + docs)
- **Resource Requirements:**
  - **Required Expertise:** Provider architecture, config/env handling, security (SSRF considerations)
  - **Dependencies:** Must ensure endpoint override doesn’t break auth headers, streaming, or introduce SSRF in hosted contexts
  - **Estimated Effort (1–5):** **2**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Add `OPENAI_BASE_URL` (or similar) setting with safe defaults.
  2. Validate URL scheme/host (especially for cloud-hosted deployments) to reduce SSRF risk.
  3. Update docs and add a minimal integration test pointing to a mock OpenAI-compatible server.
- **Potential Assignees:** odilitime (provider/plugin context), lalalune (core settings), anchapin (safe guards + tests)


### 8) Unresolved “roomId” Preventing Agent’s First Post on X — ID: DISCORD-BUG-2026-02-13-X-ROOMID
- **Current Status:** Reported on Discord; awaiting details; unresolved in provided logs.
- **Impact Assessment:**
  - **User Impact:** **Medium** (affects users trying to deploy social agents)
  - **Functional Impact:** **Partial** (blocks a common plugin-driven use case)
  - **Brand Impact:** **Medium** (social posting is a high-visibility demo path)
- **Technical Classification:**
  - **Issue Category:** **Bug**
  - **Component Affected:** **Plugin integration (X/Twitter) + runtime session/world/room handling**
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Plugin-twitter/X integration, runtime conversation identity model, logs analysis
  - **Dependencies:** Confirm runtime behavior across versions (notably v2 notes: “respond without roomId/worldId”)
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Ask reporter for: runtime version, plugin version, logs, and the exact error string/stack.
  2. Determine whether this is **pre-v2** behavior and whether a backport is needed.
  3. Add a compatibility shim: auto-create room/world context when absent for “first action” flows.
  4. Create a GitHub issue in the correct repo (likely plugin-twitter) and link it from Discord.
- **Potential Assignees:** 2-A-M (plugin-twitter focus), lalalune (runtime identity model), Odilitime (triage + repro collection)


### 9) Eliza Character File & Prompt Engineering Iteration — GitHub: elizaos/eliza **#6447**
- **Current Status:** **Open**; iterative improvements requested; test with Sonnet; add message examples.
- **Impact Assessment:**
  - **User Impact:** **Low → Medium** (quality improvement; depends on how widely “Eliza” is used as default)
  - **Functional Impact:** **No** (doesn’t block core)
  - **Brand Impact:** **Medium** (default agent quality shapes first impressions)
- **Technical Classification:**
  - **Issue Category:** **UX**
  - **Component Affected:** **Default agent config / prompts**
  - **Complexity:** **Moderate effort** (iteration + evaluation)
- **Resource Requirements:**
  - **Required Expertise:** Prompt engineering, evaluation harness/scenarios, model cost awareness
  - **Dependencies:** Availability of preferred model + cost constraints
  - **Estimated Effort (1–5):** **2**
- **Recommended Priority:** **P3**
- **Specific Actionable Next Steps:**
  1. Define success metrics: helpfulness, consistency, refusal quality, tool-use correctness.
  2. Add message examples and run scenario-based evaluations.
  3. Track changes in a small PR series (avoid bundling with unrelated refactors).
- **Potential Assignees:** borisudovicic (issue owner), lalalune (model/config), community testers coordinated by Odilitime


---

## Summary: Top Highest-Priority Issues to Address Immediately (5–10)
1. **P0:** Discord scam containment (ban scammer + restrict thread creation) — DISCORD-SEC-2026-02-15-THREAD-SCAMS  
2. **P0:** Fake support ticket impersonation hardening — DISCORD-SEC-2026-02-15-FAKE-TICKETS  
3. **P0:** Cloud chat drops image content in `/api/v1/chat/completions` — GitHub **#6494**  
4. **P1:** Duplicate LLM calls when message includes URL (double cost + duplicated output) — GitHub **#6486**  
5. **P1:** Migration fallout comms/process stabilization (reduce ongoing brand damage) — DISCORD-PROD-2026-02-15-MIGRATION-FALLOUT  
6. **P2:** Fix “roomId prevents first X post” (capture repro + file issue) — DISCORD-BUG-2026-02-13-X-ROOMID  
7. **P2:** Add configurable OpenAI base URL to support OpenAI-compatible providers — GitHub **#6490**  
8. **P2:** Base-install ElizaCloud awareness prompting for better discoverability — DISCORD-FEAT-2026-02-15-ELIZACLOUD-AWARENESS  

## Patterns / Themes Suggesting Deeper Issues
- **Trust & safety gaps in community support surfaces:** Open thread creation + ambiguous “support” pathways create an attack surface that looks “official” to users.
- **Message normalization inconsistencies:** Both **image stripping** (#6494) and **URL double-processing** (#6486) indicate fragile message conversion/parsing boundaries (text vs attachments vs previews) and insufficient regression tests around the chat payload pipeline.
- **High sensitivity to defaults/onboarding:** Multiple threads point to “what is ElizaOS / how do I use it” confusion; improving base prompts, cloud awareness, and clear docs likely yields outsized impact.

## Process Improvements (Prevention)
1. **Security-by-default for community ops:** Restrict thread creation in support-adjacent channels; publish a single official support entrypoint; add automod rules for common scam patterns (invites, “ticket”, external calls).
2. **Add regression tests for chat payloads:** Golden tests for (a) URL messages, (b) image + text multimodal messages, (c) attachment previews; ensure “one user message → one completion” invariants.
3. **Introduce incident + comms playbooks:** A lightweight runbook for scams, migrations, and other time-sensitive events (announcement cadence, pinned posts, email collection/opt-in, postmortems).
4. **Require “scope control” in PRs touching core message/runtime:** Enforce PR templates that flag message schema changes and require targeted integration tests to reduce recurring chat pipeline regressions.