What OpenHands users actually want
Every open issue across OpenHands/OpenHands, OpenHands/software-agent-sdk, and OpenHands/automation — read against Paul Graham’s evergreen rule, clustered by demand, weighted by signal, and routed to Engel’s attention or to someone else’s.
1Executive read — the top five wants, ranked
Multi-repo / cross-repo awareness
Users solve problems that span several repositories and want the agent to know about their other repos without hand-holding. The single most concentrated, repeated demand in the corpus.
Agent reliability & correctness
The largest cluster by raw volume — 249 bug-labeled issues across the three repos. Diffuse but unmistakable: the thing people want most is an agent that doesn’t stall, corrupt a session, or drop context mid-run.
Memory & context continuity
People are tired of re-explaining themselves. They want the agent to remember across sessions, carry a knowledge base, and not rot or overflow its context. This is the Engel-shaped theme.
Model routing & selection
Users don’t want to be model experts. They want the system to pick the right model per task — cheaper for trivia, sharper for hard problems — and to tune “work modes” without a PhD in pricing tables.
Integrations, automations & interoperability
The single most-reacted issue in the whole corpus is Google A2A support (#1060, 28 👍) — agents talking to agents. Around it sits a steady drumbeat for MCP coverage, Slack/Jira/Linear/GitLab webhooks, and “turn this into an automation.”
2Theme breakdown
A · Memory, context & knowledge for engel
What people want: continuity. Persistent memory that actually loads (#4542 shows the flag is silently dropped), a real knowledge base instead of re-pasting context (#16315), defense against poisoned memory (#4251, 15 💬), bounded attention over unbounded history (#16817), and output that doesn’t eat the context window (#3903). Condenser correctness bugs (#4544, #4498) and session-loss-on-restart (#4192) are the same theme’s sharp edge.
Signal: ~15 issues · strongest single-passion fit
Why Engel: the literal center of his stated obsession — memory architectures, consolidation, continuity, concept formation. The “bounded attention” and “knowledge base” asks are concept-formation problems wearing feature-request clothes.
B · Model & agent-selection policy for engel
What people want: the system to route work to the right model and expose that routing as a first-class, tunable thing. #3442 (“Intelligent Model Selection / Decide for Me”), #16235 (model-router settings), #16309 (work modes), #4654 (per-task-worker profile), #15578 (switch reasoning effort), and the skill-level model override in #2053.
Signal: ~8 issues · 12+ 💬 on the flagship · tight fit
Why Engel: “model/agent-selection policy” is named as a core interest. These asks are the policy question made concrete — classification, cost/quality trade-off, fallback — exactly the kind of simple, defensible design he favors.
C · Prompting & system-prompt architecture for engel
What people want: a prompt surface that is modular and legible rather than one monolithic template. #3606 (typed system-prompt section registry with cache tiers), #3914 (kill the Jinja fallback), #3612 (prompt-registry payoffs), custom title-generation prompts (#4561, #16761), and CLI-specific prompt variants (#4237).
Signal: ~8 issues · lower reaction volume, high architectural value
Why Engel: the “dark arts.” A typed section registry is concept-formation applied to the prompt itself — clean, non-hand-wavy, and compounding across every model and harness.
D · Harness quality & ACP comparison for engel
What people want: the best available harness, provably — and parity across Claude Code, Codex, Gemini CLI, OpenCode, Kimi, Pi, Antigravity. The “Harness Watch” series (#4627 epic, #4820 parity epic) wants automated paired comparison. Three issues (#4085, #4084, #4083) are study pages already hosted on enyst.github.io — GPT-5.6 multi-agent, WebSocket mode, tool search.
Signal: ~15 issues · #1060 is the corpus’s most 👍-ed
Why Engel: “best harness + best model” is on the list verbatim, and three of these are literally his own study pages. The comparison infrastructure is the highest-leverage, most “real” work in the set.
E · Multi-repo awareness relay
What people want: to select or auto-discover several repositories at once (#7752, #4242, #4239). Huge demand, but it is a workspace/UX problem more than an architecture problem.
Signal: ~4 issues · 15 👍 · 18 💬 on the flagship
Why relay: it’s #1 by signal but sits outside Engel’s passions — the hard part is repo discovery & selection UX, not memory or prompting.
F · Automations (product & service) relay
What people want: automations that are reliable and self-serve. UI parity with the API (#16644), “turn this conversation into an automation” (#16563), per-automation agent profile (#273) and deterministic LLM choice for reviewer/QA (#222), plus a raft of reliability bugs in OpenHands/automation — un-wired event forwarding (#318), MCP not working in triggered conversations (#93), self-hosted mode (#10), and runs hanging in RUNNING (#406).
Signal: ~50 issues (75 in the automation repo alone)
Why relay: automation-service maintainers. One sub-thread — deterministic LLM selection for reviewer/QA — does graze model-selection policy and could be worth Engel’s one-line input; flag it, don’t own it.
G · Integrations (MCP, Slack, Jira, Linear, webhooks) relay
What people want: the agent to plug into their existing toolchain. Built-in webhook sources for Linear/Slack/Jira/GitLab (#64, #59, #58, #57), a Slack/Jira/Linear/Teams/GitHub family (#16314), surfacing popular MCPs (#11004), Azure DevOps MCP (#15769), plus a cluster of MCP OAuth/connectivity bugs.
Signal: ~20 issues · steady, incremental
Why relay: integrations team. Breadth work with clear owners; none of it touches memory or selection policy.
H · Security & governance mixed
What people want: an agent you can trust with a real repo. RBAC for the canvas (#17055), enterprise SSO/RBAC/multi-org (#16312), declarative environment snapshots (#16313), per-conversation isolation (#15630), a security analyzer that doesn’t trust the model’s self-assessment (#4157), and a family of hardening asks (#2708, #2721, #3176, #3560). Secret-leak bugs (#16492, #16383, #4317, #4399) are privacy-on-the-internet territory.
Signal: ~60 issues (27 security-related + 15 security labels, plus unlabeled)
Mostly relay to security. But the privacy-on-the-internet thread — origin-readable API keys, tokens in argv — overlaps Engel’s stated privacy concern, and the “simple & defensible” security seam (#4288 reference-only credentials, #16829 deterministic bash guard) is worth his eye.
I · UX / Canvas / onboarding relay
What people want: a UI that doesn’t get in the way. The “Open the closed hands” parity epic (#9689, 29 💬), a personal conversation dashboard (#9414), onboarding redesign (#15423), timestamps & per-message cost (#6252, #15498), conversation grouping (#15677), and the Canvas-is-slow bug (#16690). The largest by volume (74 agent-canvas-labeled issues) but the most clearly-owned elsewhere.
Signal: ~90 issues · very high volume, low Engel-fit
Why relay: frontend/canvas maintainers.
J · Cost, caching & observability relay
What people want: to see where their money and tokens go, and for caching to actually register. Usage/cost dashboard (#16308), per-message token/cost (#15498), cache-hit accounting (#4491, #4817, #16835), ACP cost drift (#4382).
Signal: ~12 issues · targeted
Why relay: LLM/telemetry. Touches cost but not selection policy; it’s accounting, not architecture.
K · Infra / deploy / sandbox relay
What people want: to run this thing their way. Kubernetes-backed workspaces (#4519), Helm deployments-over-statefulsets (#17000), smolVM backend (#16354), Docker resource limits (#17090), a centralized WebSocket proxy (#16307), self-hosted mode (#10), and assorted Docker/sandbox bugs.
Signal: ~18 issues
Why relay: platform/infra.
L · Docs & onboarding friction relay
What people want: to get unblocked in the first five minutes. Bedrock docs (#15495), “how to connect to cloud” (#15947), quick-start gaps (#15795, #15797), port-allocation docs (#16866).
Signal: ~10 issues
Why relay: docs. High leverage per hour, low Engel-fit.
3For Engel — the shortlist, sorted by fit
1 · Memory & context continuity (Theme A)
The single strongest passion-fit in the corpus. Start with the concrete bug #4542 (memory silently dropped) and the architectural asks #4251 (memory-poisoning defense) and #16315 (knowledge base). #16817 “bounded attention over unbounded history” is concept-formation by another name.
Memory architectures, consolidation, continuity — the big one.
2 · Harness comparison (Theme D)
The “Harness Watch” epics (#4627, #4820) are automated paired ACP comparison — proving which harness is best, not asserting it. The GPT-5.6 investigations (#4085, #4084, #4083) are already his study pages.
Best harness + best model, made measurable.
3 · Model & agent-selection policy (Theme B)
#3442 “Intelligent Model Selection” is the policy question in a single issue. Surround it with #16309 (work modes) and #4654 (per-worker profile) for a clean, defensible routing design.
Model/agent-selection policy, explicitly named.
4 · Prompting architecture (Theme C)
#3606 — a typed system-prompt section registry with cache tiers — is the “dark arts” made legible. Lower urgency than memory, but it compounds.
Prompting, done simply and defensibly.
4Relay list — everything else, grouped
| Group | Owner-area | Representative issues |
|---|---|---|
| Multi-repo awareness | Workspace / platform + frontend | #7752, #4242, #4239 |
| Automations product | Automation-service maintainers | #16644, #16563, #273, #222, #318, #93, #10 |
| Integrations (MCP / webhooks) | Integrations team | #64, #59, #58, #57, #16314, #11004, #15769 |
| Security & governance (rest) | Security team | #17055, #16312, #16313, #15630, #4157, #2721 |
| UX / Canvas / onboarding | Frontend / canvas | #9689, #9414, #15423, #6252, #16690 |
| Cost / caching / observability | LLM / telemetry | #16308, #15498, #4491, #4817 |
| Infra / deploy / sandbox | Platform / infra | #4519, #17000, #16354, #17090 |
| Docs | Docs | #15495, #15947, #15797 |
| CI / release / dependency hygiene | Releng / CI | #4304, #16161, #14014 |
5Standout issues, one by one
| Issue | Category | Route | One-line why |
|---|---|---|---|
| #1060 Google A2A | Integrations / interop | relay | 28 👍, but protocol plumbing, not memory or selection. |
| #7752 multi-repo selection | Workspace / UX | relay | Top demand, wrong passion. |
| #3442 intelligent model selection | Model routing | engel | Selection policy in a single issue. |
| #4251 OWASP memory guard | Memory / security | engel | Memory poisoning defense = architecture + continuity. |
| #4542 load_memory ignored | Memory | engel | Real, concrete, non-hand-wavy memory bug. |
| #3992 weak-model termination | Agent reliability | relay | Core loop bug → SDK/agent-server maintainers. |
| #4627 Harness Watch epic | Harness quality | engel | Automated paired harness comparison. |
| #9689 parity epic | UX / product | relay | Parity with Suna/Manus/Devin is product, not architecture. |
| #16315 knowledge base | Memory / concept | engel | Concept formation wearing a feature-request coat. |
| #16492 API keys in localStorage | Security / privacy | engel | Privacy-on-the-internet, concrete. |
6Wide community — the second lens
OpenHands/OpenHands. The rule is applied by author login across all three repos, using the authoritative 28-login collaborators list.6.1 · The raw split
Of the 648 open issues, 400 (62%) are maintainer-authored and 248 (38%) are wide-community. Maintainers write the vast majority — so the all-community view is heavily self-authored. Here’s the split per repo:
| Repository | All | Maintainer | Wide community |
|---|---|---|---|
| OpenHands/OpenHands | 355 | 219 | 136 |
| OpenHands/software-agent-sdk | 218 | 122 | 96 |
| OpenHands/automation | 75 | 59 | 16 |
| Total | 648 | 400 | 248 |
6.2 · Top wants — wide community only
Re-ranked on the 248 non-maintainer issues. The headline: what rises is the unglamorous crawl — errors, stalls, sandbox/install friction, and model-provider coverage — while maintainer-authored roadmap/parity items dominate the all-community view.
Unblocks & reliability: the agent stalls, errors, and gets stuck
The single biggest real-world complaint from non-maintainers is that the agent goes quiet, times out, or dies mid-run. This is bare-metal, essential “don’t break” demand — the same theme that was already #2, but here it’s #1 by a wide margin.
Model / LLM provider coverage
Non-maintainers are constantly hitting the edge: their local or niche provider (LM Studio, ollama, Workers AI, Azure) doesn’t work, or they want a universal OpenAI-compatible endpoint. Maintainers don’t file these — they build them; the users tripping over them are the broad base.
Memory & context continuity (rises — now mostly user-authored)
Memory climbs into the top three in the wide view, and its anchors are user issues here: the knowledge-base ask (#16315), bounded attention (#16817), memory-poisoning defense (#4251), and context overflow (#3903). The one maintainer bug from the all-view (#4542) isn’t the anchor anymore — the demand is community-led.
Docker / sandbox / install friction (rises)
Getting the thing running at all is a top non-maintainer concern: quickstart bind-mount failures, missing Chromium flags in the Docker image, and self-hosted mode. This barely registered in the all-community view because maintainers start the service already-installed.
UX polish & the “open hands” parity intent
The broadest UI asks are concrete and small: a usable onboarding explanation, a VS Code tab for local servers, themes, per-message cost/timestamps — plus the biggest single issue, the community-authored “Open the closed hands” parity epic (#9689, 29 💬, filed by a non-maintainer).
7The delta — what changes when you drop maintainer-authored issues
7.1 · Rises
| Theme | All view | Wide view |
|---|---|---|
| Agent reliability / stalls / errors | #2 | #1 |
| Model / LLM provider coverage | #4 | #2 |
| Memory & context continuity | #3 | #3 (but now user-authored) |
| Docker / sandbox / install friction | barely listed | #4 |
7.2 · Falls
| Theme | Why it falls |
|---|---|
| Multi-repo awareness | Its top issues are all maintainer-authored — #7752 (neubig), #4242 (enyst), #4239 (jpelletier1), #15758 (jpelletier1). It’s real demand, but it’s demand maintainers are already tracking themselves, so it’s invisible in the wide lens. |
| Harness comparison (Harness Watch / ACP parity) | Filed almost entirely by maintainers (#4627, #4820, #1060). A maintainer priority, not yet a community pull. |
| Prompting / system-prompt registry | Almost entirely maintainer-authored (#3606, #3914). Deep architecture the broad base doesn’t articulate. |
7.3 · Only shows up in the wide lens
The things the broad base asks for that maintainers aren’t already tracking themselves:
- The agent goes quiet / stalls / doesn’t tell you what’s wrong. #4246 “agent remains idle, no feedback” (11 💬), #3992 “weaker/local models terminate agents” (13 💬), #4245 webhook container crashes (11 💬).
- Local/niche model coverage. LM Studio (#4247), ollama (#4255), Workers AI (#4250), Azure (#4549) — a long tail of “my provider doesn’t work.”
- Self-hosting & sandbox ergonomics. Self-hosted mode (#10), resource limits (#17090), smolVM backend (#16354), Kubernetes workspaces (#4519), statefulsets vs deployments (#17000).
- Enterprise surface. SSO/RBAC/multi-org (#16312) and declarative environment snapshots (#16313) — both filed by a single non-maintainer (afonsoft), but they represent an un-owned adoption lane.
8A note on method & honesty
This page was generated by fetching every open issue (state=open, PRs excluded) from OpenHands/OpenHands (355), OpenHands/software-agent-sdk (218), and OpenHands/automation (75) via the GitHub REST API with full pagination, on 2026-09-02. Signal was weighted as number of issues in a cluster × comment count × reaction count, and themes were formed by reading titles and bodies rather than by label alone, so counts are deliberately approximate (“~N issues”). Every issue number cited here is a real, currently-open issue with a working link — nothing is invented. The Engel-vs-relay calls are a judgment about where each ask overlaps a named passion, not a measure of importance; several “relay” items are higher-signal than the “Engel” items and are marked as such.
Wide-community rule: an issue is “wide community” if its author login is not in the authoritative 28-login collaborators list for OpenHands/OpenHands (write access): DevinVinson, VascoSch92, aivong-openhands, ak684, all-hands-bot, chrisnelson-design, dylan-openhands, enyst, erisfully, hieptl, huybery, jlav, jpelletier1, jpshackelford, juanmichelini, li-boxuan, lilagrc, malhotra5, mamoodi, neubig, openhands-agent, owensweeney-spec, rajshah4, rbren, ryanhoangt, saurya, simonrosenberg, tofarr. This filter treats the bot accounts (all-hands-bot, openhands-agent, aivong-openhands, dylan-openhands) as maintainer-authored, correctly excluding them from the wide view.