OpenHands 1.18 Tightens Automation Permissions and Cloud Agent Controls

By AiCybr Editorial · Published September 16, 2026

OpenHands released Agent Canvas 1.18.0 on September 11, 2026, extending the automation and cloud-management changes introduced in 1.17.0 two days earlier. Version 1.18 adds creator-only automation reactivation, cloud-side automation editing, execution-identity visibility, database-driven model flags and exhaustive decision handling for ACP harnesses added through the registry.

The release is available as Windows, macOS, Debian and AppImage desktop packages. OpenHands also publishes the project under the MIT License and documents Agent Canvas as the control layer for a multi-repository agent stack that separates the UI, Agent Server, TypeScript client and automation service.

For teams running scheduled or event-driven coding agents, the main operational change is tighter control over who can manage an automation, which identity executes it and how cloud-backed automations are edited. Those changes build on 1.17, which separated automation permissions into view/manage capabilities, added custom cron editing and enabled generic automation manifests in Canvas.

OpenHands 1.18 at a glance

OpenHands 1.18 follows 1.17.0, released September 9, which delivered the larger automation-control foundation. That release added task-outcome-aware automation run UI, custom cron editing, cloud LLM-provider connections, local Planner support, conversation tags, generic automation manifests and separate view/manage automation permissions.

The permission model is becoming more explicit

OpenHands 1.17 split automation access into view and manage capabilities and added a creator-oriented recovery path. Version 1.18 narrows the reactivation path further by allowing only the automation creator to turn a disabled automation back on.

This matters for long-running coding agents because re-enabling an automation can restore access to repositories, credentials, network services and model endpoints associated with that job. A disabled automation can represent an intentional operational or security boundary. Creator-only reactivation gives administrators a clearer ownership model for restoring execution.

Version 1.18 also shows the identity used by an automation. That is useful in environments where agents can run under different service identities, organization contexts or credential sets. Operators can verify the execution principal before changing schedules, permissions or connected services.

A practical review after upgrading should include:

1. list active automations and confirm their owners;
2. verify the displayed execution identity for jobs with repository or infrastructure access;
3. review who has automation-management permission;
4. confirm disabled automations remain disabled unless their creator intentionally restores them;
5. re-check credentials and model-provider connections used by high-privilege workflows.

Cloud-backed automations can now be edited in Canvas

OpenHands 1.18 allows editing automations on cloud backends. Combined with 1.17's unified cloud-settings entry point and cloud LLM-provider connections, Agent Canvas is moving more operational configuration into one control surface.

That reduces the need to manage a hosted automation through separate interfaces. The change is especially relevant for teams using recurring repository maintenance, issue triage, scheduled code analysis or other jobs that execute without an interactive user session.

OpenHands also fixed several cloud-context issues in 1.18. The active organization is now passed from the settings entry point, unlisted settings pages are hidden when Canvas is locked to a Cloud host, and Cloud settings open in the same tab in that configuration.

Those fixes are small individually, yet they address a common multi-tenant administration problem: configuration actions should retain the correct organization and backend context throughout the UI flow.

OpenHands 1.17 added custom schedules and generic automation manifests

The 1.17 release expanded the automation layer in several ways that are directly relevant to 1.18 deployments.

Custom cron expressions

Users can edit a custom cron expression from the automation editor. This supports schedules outside simple hourly or daily presets and gives operators direct control over execution windows.

For production use, custom schedules should be reviewed alongside model rate limits, repository maintenance windows and external API quotas. A high-frequency cron schedule can increase token usage, concurrent agent load and downstream service traffic.

Generic automation manifests

Canvas can display and work with generic custom automation manifests. This broadens the UI beyond a fixed set of built-in automation types and gives teams more flexibility to package organization-specific workflows.

The manifest path also increases the importance of permission review. A reusable automation definition can connect scheduling, agent configuration and backend execution, so its owner and execution identity should be visible and auditable.

Task-outcome-aware run UI

Version 1.17 made the automation run interface aware of task outcomes. Operators get a clearer view of whether a run completed the intended task instead of relying only on low-level execution state.

For unattended agents, task outcome is the useful operational unit. A process can exit successfully while the requested repository or infrastructure change remains incomplete, so surfacing the task result helps with run triage.

ACP harness registry decisions are now exhaustive

OpenHands 1.18 changes the ACP harness registry so registry code must make an explicit decision for every harness it adds. This is an implementation-level exhaustiveness rule for the registry, helping ensure new ACP harnesses receive deliberate handling instead of falling through an implicit default.

Harnesses can differ in the execution environment they expose around an AI model, including tool, command and file-operation capabilities. The 1.18 change improves the maintainability of the registry as harnesses are added; the release notes do not describe it as a new deployment-time allow/deny control for Canvas operators.

Teams using multiple agent backends should continue documenting the harnesses they intentionally deploy and the capabilities and identities associated with them, using the operator-facing controls their deployment actually provides.

Agent Canvas is only one layer of the OpenHands stack

The current OpenHands repository documents Agent Canvas as the user-facing control center in a multi-repository architecture:

The Agent Server can run on a local machine, dedicated host, cloud VM or OpenHands Cloud. Agent Canvas can connect to multiple Agent Servers. The automation service determines when work runs and dispatches conversations, while the Agent Server and SDK determine what executes.

That separation is important when troubleshooting a scheduled agent. A failure can originate in the automation definition, dispatch layer, server connection, model provider, workspace or tool execution path. Treating Canvas as the entire runtime can hide the actual fault domain.

Desktop packages and deployment options

OpenHands 1.18 ships desktop artifacts for the main workstation platforms:

• Windows installer (.exe)
• macOS Apple Silicon disk image (arm64.dmg)
• Debian package (amd64.deb)
• Linux AppImage

The project repository is MIT-licensed. OpenHands documents local and remote Agent Server deployment, including dedicated machines and cloud virtual machines, with Canvas acting as the operator interface.

For self-hosted environments, keep the Agent Server and automation service on hosts that match the trust level of the repositories and credentials they can access. Agent execution commonly includes shell commands, file modifications and external-service access, so infrastructure isolation remains part of the security model.

Upgrade checklist for 1.18

Teams moving from an earlier Agent Canvas release should verify the following after deployment:

1. Confirm the running Canvas version is 1.18.0 where the new controls are required.
2. Review automation owners and identify workflows whose original creator is unavailable or no longer appropriate.
3. Check execution identities shown for scheduled and event-driven automations.
4. Test cloud automation editing with the correct organization selected.
5. Review view/manage permissions introduced in 1.17 and align them with operational roles.
6. Inspect custom cron expressions for unexpected frequency, concurrency or cost impact.
7. Inventory deployed ACP harnesses and verify their capabilities against the controls and policies available in your environment.
8. Validate LLM provider connections, especially in cloud-backed Canvas deployments introduced or changed during the 1.17 upgrade.
9. Run one representative automation manually and confirm the task outcome, repository changes and audit trail.
10. Retest disabled-job behavior so reactivation follows the intended ownership path.

Bottom line

OpenHands 1.18 is an incremental release with a clear administrative theme: automation ownership, execution identity and cloud configuration are becoming more explicit. Its value is easiest to see together with 1.17, which introduced separate automation permissions, custom schedules, generic manifests and cloud provider connections.

For individual local users, the visible changes are modest. For teams operating unattended coding agents, the 1.17–1.18 release line provides better controls for answering two operational questions directly: who can change the automation and which identity will run it. Harness-registry exhaustiveness is a separate implementation-level improvement for newly added ACP harnesses.

Sources

• OpenHands — v1.18.0 release, September 11, 2026: https://github.com/OpenHands/OpenHands/releases/tag/v1.18.0
• OpenHands — v1.17.0 release, September 9, 2026: https://github.com/OpenHands/OpenHands/releases/tag/v1.17.0
• OpenHands — OpenHands repository and architecture overview: https://github.com/OpenHands/OpenHands