Quick Answer
OpenHands has replaced its agent secret-request modal with a card inside the chat. When an agent calls request_secret for a missing credential, the user can answer in the conversation while revised instructions encourage independent work. PR #18575 merged into main on October 17 KST. A published release tag containing the commit was not verified.
In Plain English
Imagine asking a coding assistant to prepare a change and push it to GitHub. Preparing the change might be possible immediately, but pushing it could require your token. A secret request lets the assistant ask for that credential through a dedicated form rather than ordinary chat text.
Previously, the form appeared over the conversation, and the tool instructions told the agent to end its turn and wait. The merged first-parent diff changes both pieces: the form becomes part of the timeline, and the instructions permit work that does not require the credential. That separates a pending user decision from tasks that could still move forward.
Code Evidence
The implementation has three distinct responsibilities: placing the request, instructing the agent, and completing the existing credential workflow. These should not be treated as one new capability.
In messages.tsx, the renderer matches each pending request’s tool-call identifier against action or observation events. It anchors the card to the matching event, before later conversation content. If that event is unavailable in the loaded messages, the request falls back to the end of the chat. This preserves a visible place to answer even without its original anchor.
The new SecretRequestCard filters pending requests by conversation and reuses SecretForm. It displays the reason, prefills the requested name, and connects save and cancel callbacks to completion. Its value field uses two visible rows; the shared form retains its eight-row default elsewhere. A failed save leaves the form available for retry or cancellation.
The existing request service handles attachment and reporting. Saving attaches the credential to the running conversation and reports its name with a saved status. Cancellation reports not_saved without attaching a value. The shortcut that attaches an already-saved credential without showing a form predates this change.
The supplied anchoring tests assert placement before later messages and fallback ordering. Their simulated messages establish rendering expectations, not actual agent progress.
Why It Matters
Acknowledging a request and completing it are different events. The client tool is acknowledged before the user answers; that acknowledgement does not mean a credential is available. A later completion message tells the agent whether the user saved or cancelled, including the final name if the user changed it.
The revised instructions, visible in the diff, tell the agent to pursue independent work, end its turn when none remains, and avoid repeated requests or waiting loops. They express intended behavior rather than demonstrate model compliance.
The service also separates credential delivery from outcome reporting. The value is attached through the conversation-secret mechanism; the result event carries status, name, and applicable guidance rather than the value itself. That describes this reporting path, not a comprehensive security guarantee.
Keeping the request beside its originating event may help users understand why it exists while following subsequent work. That is a design inference, not a measured usability result. The separate overview schematic likewise depicts intended independent work, not observed agent behavior.
An Open Question
Does the revised tool instruction lead a real LLM-backed agent to make useful progress on work that does not need the pending secret, then interpret the saved or cancelled result correctly?
An actual integration and evaluation matrix would resolve this: use a real agent server and LLM, test tasks with and without independent work, and exercise both save and cancel. Inspect subsequent actions, active-conversation attachment, and result events containing status and name without the value. No such evaluation was performed for this article.
Scope and Limitations
This analysis uses the supplied official first-parent diff and research. Test sources were inspected, not executed. The PR author reported 828 passing tests across 69 files, type checking, pre-commit checks, and desktop and phone mock Canvas runs, but explicitly reported no end-to-end run against a real agent server and LLM.
The PR recorded 15 of 19 checks passing, including reported failures in verification-skill isolation and description validation; it was not fully green. These findings establish source changes, not runtime, performance, or security guarantees. Main contains the merge, but inclusion in a published tag on the official Releases page remains unverified.
Sources
Official sources checked October 19, 2026, in the supplied research: