GitHub Repo
OpenHands 1.24 fixes MCP authorization refresh, addressing tools failing after token expiry
The release preserves cloud OAuth state and pairs that change with SDK fixes for token refresh endpoints and state writeback. The full effect still depends on backend deployment, and existing connections need validation across conversations.
OpenHands released 1.24.0 on September 25, including a fix for MCP cloud authorization and an upgrade to SDK 1.49.6. These changes address a problem where an agent connects successfully at first but loses access to external tools after its access token expires. [Release announcement](https://github.com/OpenHands/OpenHands/releases/tag/v1.24.0)
MCP lets agents load tools provided by external servers and forward calls to them at runtime. According to the official documentation, OpenHands reads the configuration, establishes a connection, and registers the tools. Reliable authorization refresh therefore affects whether later tasks can access the same capabilities. From an engineering perspective, testing only the initial setup is not enough to catch failures that emerge over time. Scheduled jobs running the next day and workflows that repeatedly rebuild sandboxes especially need credential lifecycle validation. [MCP documentation](https://docs.openhands.dev/overview/model-context-protocol)
Maintainers said the old cloud storage flow flattened OAuth credentials into a fixed Bearer header, discarding the authorization state that included the refresh token. As a result, GitLab connections could fail after about two hours. The new version preserves OAuth state and clears the old header when saving again. If the server determines that consent is not needed again, the frontend polls for the job result instead of treating the missing authorization URL as an error. [Frontend fix](https://github.com/OpenHands/OpenHands/pull/17677)
The SDK also fixes another failure path: a client created for a new conversation could send refresh requests to the wrong default endpoint. The new implementation first discovers the authorization server's metadata to find the correct endpoint, then writes the sandbox's updated state back through a webhook so the next conversation can use the rotated token. [SDK fix](https://github.com/OpenHands/software-agent-sdk/pull/5306)
SDK 1.49.6 was published to PyPI the same day and requires Python 3.12 or later. Maintainers reported that 74 frontend-related tests and 67 SDK and agent server tests passed. These are project test results and do not prove that all providers and hosted environments have recovered. [Package page](https://pypi.org/project/openhands-sdk/1.49.6/), [frontend tests](https://github.com/OpenHands/OpenHands/pull/17677), [SDK tests](https://github.com/OpenHands/software-agent-sdk/pull/5306)
Deployment still requires checking that the application server runs a compatible version: the complete fix spans the frontend, SDK, and cloud backend, and public release records cannot confirm that every hosted environment has been updated. If writeback fails, the new token can still be used for the current run, but persistence across conversations may fail. Engineering teams should verify that tools load after token expiry and remain available after a sandbox is rebuilt, and monitor writeback warnings. Connections saved using the old flow should also be checked to ensure the refresh token is still present; if it has been lost, reauthorization may be needed to restore the complete state. [Deployment limitations](https://github.com/OpenHands/OpenHands/pull/17677), [writeback behavior](https://github.com/OpenHands/software-agent-sdk/pull/5306)