Signals / OpenHands profile

OpenHands

Sourced signals for OpenHands: release changes, governance moves, runtime shifts, and operator consequences. Each links to the run that produced it. The OpenHands profile carries the current evergreen state.

July 2026

  1. 2026-07-01 / OpenHands

    OpenHands shipped its dependency-CVE fixes on the cloud channel; the OSS 1.8.0 line is frozen and a new CVE already sits untagged on main

    • Last window's unreleased dependency-CVE batch reached tags this window -- but only on the CLOUD channel: cloud-1.39.0 (2026-06-24, ~16-item CVE/dependency batch) and cloud-1.40.0 (2026-06-26, a 4-item CVE/GHSA batch). The OSS line got NO new tag; the newest non-cloud release is still 1.8.0 (2026-06-10).
    • It is worse than merged-vs-shipped: it is now cloud-vs-self-host. A managed OpenHands Cloud tenant is patched; a self-hoster on the 1.8.0 tag is not, with no fixed OSS tag to move to. And a fresh authlib CVE (CVE-2026-44681 -- an unauthenticated open redirect in Authlib's OIDC grant, CWE-601, phishing-grade at CVSS 6.1; commit e6fe505) already sits on main after cloud-1.40.0 -- untagged again.
    • Determine your channel and act on it: on Cloud, you are covered; on the OSS 1.8.0 tag, you are unpatched for this batch and must either run a build from main (inheriting all its churn) or wait for an OSS tag that has not come for three windows.

June 2026

  1. 2026-06-24 / OpenHands

    OpenHands shipped a five-item dependency-CVE batch to main on 2026-06-23 -- in no tagged release

    • A batch of dependency security fixes landed on `main` on 2026-06-23 -- CVE-2026-44727 (jupyter-server 2.20.0), CVE-2026-49458 (dompurify 3.4.6), GHSA-6v7p-g79w-8964 (msgpack 1.2.1), CVE-2026-45409 (idna 3.15), GHSA-gj48-438w-jh9v (bleach 6.4.0) -- but no tag was cut; the only release remains 1.8.0 from 2026-06-10.
    • Determine which channel you run. An operator on 1.8.0 has none of these fixes; an operator on a build from main has them. This is the same merged-vs-shipped gap that defined last window, now continuing into this one -- 'fixed' is true on main and false in the binary most operators run.
  2. 2026-06-23 / OpenHands

    API-key auth decoupled from Keycloak — IdP session revocation is no longer a kill switch for machine keys

    • PR #14867 (merged to main 2026-06-17, NOT in any tag) decouples API-key (Bearer) auth from Keycloak offline sessions: API-key authentication performs zero Keycloak round-trips, so a revoked or expired IdP session no longer invalidates a machine key. Headless clients stop hitting opaque 401s — but the revocation contract changed.
    • Operators who relied on Keycloak session revocation to kill machine keys must now revoke at the key store instead. This is on main, in no release.
  3. 2026-06-23 / OpenHands

    Last window's per-org concurrency limits reverted outright in-window

    • PR #14877 (merged to main 2026-06-17) reverts the DB-backed per-org/per-user concurrent sandbox/conversation limits from #14168, adding migration 124 to drop the columns introduced by migration 120. The 429-based quota some operators were waiting for is not coming in the next 1.x; the surviving concurrency-control path now counts from the runtime `/list` API rather than a DB flag.
    • Operators who anticipated 429-based concurrency enforcement must not plan around it — it was withdrawn, not enforced.
  4. 2026-06-23 / OpenHands

    An entire OpenHands enterprise and security build-out, two windows unreleased (postcss CVE + git-token redaction)

    • The only mainline release is still 1.8.0 (June 10). Two security fixes that matter to anyone on a build from main are in no tag: the moderate postcss XSS, CVE-2026-41305 (#14770), and a fix that stops a `PluginSpec.source` containing an embedded git token from being written to the database in plaintext (#14795). New writes are redacted.
    • Operators on 1.8.0 have none of this and are not patched. Operators on a build from main should rotate any git token that was embedded in a repo source URL, because pre-fix writes were stored plaintext.
  5. 2026-06-23 / OpenHands

    Sandbox-spec authority moves off a hardcoded list onto a runtime-api control plane

    • PR #14849 (merge 56034afe10, merged to main 2026-06-16, NOT tagged) adds a DynamicRemoteSandboxSpecService that fetches available sandbox specs from the runtime-api `GET /api/warm-runtime-configs` endpoint rather than a hardcoded preset list — the foundation for custom and per-tenant execution images, with a companion guardrail refusing a custom image whose agent-server SDK version does not match.
    • Operators planning custom or per-tenant execution images should track this; the sandbox is becoming a server-driven, configurable surface. It is on main, in no release.
  6. 2026-06-23 / OpenHands

    A per-user OAuth token now follows the user into the sandbox from any conversation start path

    • PRs #14697 and #14650 (merged to main 2026-06-16, NOT tagged) generalize a per-user secret enricher that injects a user's linked Jira Data Center OAuth token into the sandbox from any conversation start path — web, Slack, and API — not just the originating Jira integration. A credential now follows the user into the runtime, with the blast radius that implies.
    • Operators must reason explicitly about which start paths carry which secrets into a sandbox; the credential plane widened. It is on main, in no release.
  7. 2026-06-15 / OpenHands

    Concurrency becomes a governed, billable resource (Personal 3, commercial 10; unreleased)

    • PR #14168 (main, unreleased) caps concurrent conversations/sandboxes (Personal=3, commercial=10) with per-org and per-user override columns and HTTP 429 enforcement. A real resource-control and economics surface; tightens the free tier.
  8. 2026-06-14 / OpenHands

    Admins can lock an org to a curated model set and hide custom-key fields (unreleased)

    • PR #14773 (main, unreleased) adds allow_user_llm_configuration: off hides custom model/base-URL/API-key inputs and locks the org to a curated, proxy-served model set. The platform owns the model-access policy, not the user.
  9. 2026-06-13 / OpenHands

    Plaintext git tokens in the DB, a plaintext MCP key, and two frontend CVEs

    • OpenHands stopped persisting PluginSpec.source git tokens in plaintext in the DB (#14795, main) and stopped round-tripping remote MCP API keys in plaintext (#14613, main); react-router CVE-2026-42342 shipped in release 1.8.0 (uncredited), postcss CVE-2026-41305 is on main. Rotate any token embedded in a repo source URL or MCP config before the fix; rebuild the frontend.
  10. 2026-06-10 / OpenHands

    OpenHands Enterprise: the first user to log in owns the organization (unreleased)

    • PR #14752 (main, intended for an untagged 1.39.0) makes the first user to sign in after enabling the default org its owner, keyed to an is_default DB flag (migration 119). The multi-tenant foundation the window's enterprise work stacks on. Operators must control who signs in first.
  11. 2026-06-10 / OpenHands

    hide_personal_workspaces is explicitly UI-only, not an access boundary

    • PR #14741 (main, unreleased) hides personal workspaces in org-only installs but the docs state it is UI-only: the orgs API still returns personal orgs and there is no server-side enforcement. Operators must NOT treat it as an access-control boundary; the real boundary is the membership model.
  12. 2026-06-03 / OpenHands

    Upgrade frontend deps (axios 1.16.0, dompurify 3.4.0) to close CVE-2026-44492 and CVE-2026-41238

    • Two browser-facing frontend dependencies were patched in the window: axios to 1.16.0 (CVE-2026-44492, commit 73d1d9a) and dompurify to 3.4.0 (CVE-2026-41238, commit b025cd2). Two commits, one operator action: rebuild and redeploy the frontend bundle.
    • Self-hosters pinning older lockfiles must bump both manually; a stale frontend build leaves both CVEs live.
  13. 2026-06-03 / OpenHands

    Upgrade dulwich to 1.2.5 to close CVE-2026-42305 in git operations

    • Operator must re-resolve poetry.lock (enterprise and root) and rebuild backend images to ship patched dulwich; git operations run inside the agent runtime path.
    • Distinct from the frontend CVEs: this is a backend Python git library, different surface and different verification (lockfile pin, not frontend bundle).
    • Verification path: confirm dulwich>=1.2.5 in deployed poetry.lock / installed environment.
  14. 2026-06-03 / OpenHands

    ACP provider credentials now route through cipher-protected agent_context.secrets, not acp_env

    • Operators running ACP agents must understand provider API keys/base URLs now flow through the cipher-protected secrets channel; the deprecated acp_env channel no longer carries credentials.
    • Changes the persistence and exposure surface for agent provider credentials, with SDK gap-fill logic specifically preventing re-folding into the insecure acp_env channel.
    • Verification path: confirm ACP provider creds appear via agent_context.secrets and are absent from acp_env in agent context.
  15. 2026-06-03 / OpenHands

    DELETE /api/organizations now cascade-deletes the sole-org requester (personal org)

    • Operators must understand that deleting a personal org now also deletes the requesting user account, enabling re-onboarding on next login — a destructive identity-state change behind one endpoint.
    • Changes operating-state semantics of an existing destructive API: requires backup discipline before org deletion; multi-org members are protected by preflight orphan detection.
    • Verification path: test DELETE /api/organizations against a sole-org account vs a multi-org member and confirm orphan-rejection behavior.

May 2026

  1. 2026-05-27 / OpenHands

    OpenHands becomes the GUI shell for other harnesses, with org-level LLM profiles

    composes with Claude Code , Codex , Gemini CLI

    • Evaluators of OpenHands as a multi-agent shell: enable `ENABLE_ACP` against your preferred ACP back-end (Claude Code, Codex, Gemini CLI) and test the policy surface — the greyed-out settings while ACP is active are intentional.
    • Multi-tenant SaaS operators must confirm they are on 2026-05-22+ to get the MCP/ACP env scoping fix. Audit MCP credentials that may have been shared across org members pre-fix.
    • Enterprise admins should treat the org-level LLM profile model as the canonical place to set 'this org uses these models' policy.
    • Operators on the release channel need to know none of this is in a tagged 1.x release yet — main-branch only.
  2. 2026-05-12 / OpenHands

    Sub-agent delegation (opt-in) and critic evaluation GUI

    • Operators running multi-task sessions can now enable sub-agent delegation via `enable_sub_agents`. Built-in sub-agents (bash-runner, code-explorer, general-purpose, web-researcher) handle scoped tasks with restricted tool surfaces. Default is off -- enable deliberately.
    • Operators should configure `CRITIC_API_KEY` to route critic evaluation spend separately from the primary model key if centralized cost control matters.
    • The critic display is deployment-controlled via `OH_ENABLE_CRITIC_BY_DEFAULT` (disabled by default). Deployments that want it enabled should set that flag; per-deployment toggle is `verification.critic_enabled`.
  3. Real computers are becoming the agent work surface.

  4. 2026-05-07 / OpenHands

    Agent harnesses are becoming full development platforms.

  5. Accessibility is becoming a frontier capability.

  6. The agent interface is becoming a visible computer

    • A serious agent harness increasingly needs browser, desktop, file, runtime, sandbox, and artifact surfaces that can be inspected.
  7. Permissions, secrets, and sandboxes are moving into the foreground

    • The harness must make trust state visible: what can be read, what can be changed, which credentials are exposed, and where execution happens.
  8. Accessibility is a frontier capability, not marketing polish

    • Everyday adoption depends on setup recovery, visible progress, voice/chat surfaces, readable UI, OAuth clarity, and fewer dead ends.
  9. Agent systems are growing control planes

    • Once agents coordinate across tasks, runtimes, gateways, and integrations, operators need liveness, cost, role, session, and recovery controls.
  10. Integrations are volatile; the operating loop has to be durable

    • Provider lists, plugin systems, transports, and model profiles will keep changing.

<- All signals