Start here: browser workflows, wallet QA, and feedback

[Hronom]

Welcome to Hronaut Discussions! Use this space to ask about a workflow, share a reproducible example, or explain what makes a browser task difficult to automate.

Hronaut is a visible, persistent local browser workspace for coding agents over MCP. Your agent handles task planning; Hronaut provides the browser state and tools, with human setup and takeover when needed.

Hronaut v2.4.29 is published in the official MCP Registry as io.github.hronaut/hronaut. That record points to the version-matched MCPB adapter; it does not install or start the Hronaut desktop app, turn the loopback endpoint into a hosted service, or establish compatibility with every graphical MCPB host. Install and run the matching desktop release locally first, then follow the MCPB adapter guide. The v2.4.29 release also adds cross-platform launch-at-sign-in options, documents the Registry identity and local-desktop requirement, hardens Linux autostart parsing and bounds wallet-agent session expiry by monotonic elapsed time.

See the tested workflows

Workspace continuity — 34-second MP4: a local page and its checked state survive an MCP client disconnect; a new test client needs the private resume capability, not just the workspace ID. Ten executed checks, captions and limits.

Local EVM wallet QA — 45-second MP4: reject, submit once, read a pending receipt, then confirm the same hash after mining on disposable Anvil. The test harness operates the trusted approval controls—it is not an agent approving itself. Twenty executed checks, captions and limits.

Both recordings show real 2.4.24 source builds with synthetic/local examples at original speed. They are bounded runtime demonstrations, not installer, named AI-client, app-restart, external-wallet or security-audit results. Production tooling and explanatory captions are AI-assisted. The suggested first-run exercise below is separate; the clips do not claim to execute every step of it.

Start with one small workflow

Start without personal accounts, credentials or a wallet:

1. Verify and start the desktop app, then follow the setup guide for your local coding agent. Use Home's current client configuration; connect only clients you trust.

2. Give the agent this bounded prompt:

   Using Hronaut, create a new isolated workspace named “Hronaut first run” with scratch storage. Open https://example.com in it, take a semantic snapshot, report the heading, and wait. Do not use or copy an existing workspace or the Default workspace.

3. Confirm the named workspace, visible Example Domain page and matching reported heading. App/listener health, advertised tools, tools visible to your client, and a successful browser action are separate checks.

4. Use Pause agents, inspect any action already in flight, manually follow the page's link to IANA, then resume and ask for a fresh snapshot in the same workspace. Check whether the agent observes your navigation. Pause blocks new commands; it does not cancel or undo already dispatched work.

5. End the agent conversation while leaving Hronaut open. Check that the workspace remains in the browser. This does not test restarting the app or automatically authorize a new client session: a different MCP session needs the private resume capability. Never include it in a public report. See the starter workflows for the full scope and archive behavior.

For each step, report passed, failed, not attempted or unknown, with the app/client versions and OS. These are suggested checks, not results claimed on your behalf. Afterward, archive/remove only the disposable workspace created for this check when it is no longer in use. Before trying a signed-in site, use the documented authentication and human-handoff flow; never send credentials or token values to the agent. Reconcile an uncertain outcome before repeating a consequential write.

Hronaut is source-available under its Subscription and Trial License: one 10-day trial from the first agent tool call, then $4/month or $24/year per named user, up to three active devices. No credit card or automatic billing during the local trial. Downloads are currently unsigned/not Apple-notarized; use the release verification guide.

Building a dApp or testing wallet flows?

The local EVM wallet QA quickstart uses a disposable Anvil chain and fixture dApp. It walks through provider discovery, connection and approval rejection, account/network changes, and successful, delayed and reverted receipts. The v2.4.29 fixture correlates requests while keeping sensitive values out of its visible log; provider invocation and independent receipt reads remain separate evidence. A transaction hash means submitted, not confirmed.

The local-wallet preview has been included since 2.4.21; its API may evolve. It uses Hronaut's own provider, not MetaMask/Phantom/TronLink emulation or WalletConnect/Reown. Keep real-extension tests for wallets your app explicitly supports. Wallet import, initial permissions and trusted approvals in this guide are human steps. Use only disposable local-chain accounts—never a funded wallet or real recovery material.

Where to post

• Q&A: setup questions and help with a specific workflow.
• Setup report: use the structured setup-feedback form for a successful or failed connection; successful reports are useful too. Never include credentials, MCP tokens, private URLs or personal browser-session data.
• Ideas: describe the problem you need solved, the current workaround and what a useful result would look like.
• Show and tell: a small working example, with its version, limitations and any AI assistance disclosed.
• GitHub Issues: reproducible, non-sensitive bugs and concrete feature requests. Search first so related evidence stays together.

For a useful report, include the Hronaut version, operating system, MCP client, expected versus observed result, and a minimal public or synthetic reproduction. Remove account identifiers, cookies, tokens, license keys, private URLs and customer data. Do not paste raw logs or screenshots until you have checked them for sensitive content.

Security vulnerabilities should be reported privately using the security policy, not in a public discussion or issue.

What is the first browser workflow—or wallet-QA case—you would like to make repeatable?

Maintainer post prepared with AI assistance; first-run instructions refreshed September 20, 2026 against the v2.4.29 sources. This is an evaluation recipe, not an additional executed desktop/dApp test, universal client-compatibility claim or independent security audit.

[rohit-binaried]

A workflow I would like to evaluate is a React application where a person and an agent share the same state: the person changes a value, the agent reads it, a proposed write waits for approval, and declining leaves state unchanged. Navigation while approval is pending would be another useful boundary to observe.

I maintain RCIP and have a small account-free React starter for that application-side behavior. Its browser checks pass independently, but I have not run it with Hronaut. Browser UI interaction and an RCIP client integration would be separate experiments; the latter needs a bridge.

Would that be a useful owned-app QA case for your feedback series? This comment was drafted with AI assistance; it describes a proposed experiment, not Hronaut compatibility results.

[Hronom]

Yes—this is a useful, bounded case for the feedback series. Starting with browser UI interaction, without an RCIP bridge, keeps the experiment clear.

I read the starter guide and checked the larger hosted demo in ordinary Chrome today (September 19), not the standalone starter or Hronaut:

• Added a synthetic todo through the normal UI; the SDK control panel's todos.list returned the same item.
• Requested another todo, observed confirmation_required with no new item, then clicked Cancel. The outcome was CONFIRMATION_DECLINED; a fresh todos.list still returned the original five-item list.
• Started a separate request, switched Todos → Profile while confirmation was pending, then clicked Confirm capability. It returned POLICY_DENIED (application changed). Returning to Todos and invoking a fresh list again showed the same five items.

These are observations of the hosted demo, not Hronaut compatibility, a connected LLM, human-identity proof or full document-navigation coverage. I operated the test UI, including its confirmation controls.

For a first Hronaut run, I'd keep three checks separate: manual UI change → fresh agent read; proposed application write → human decline → fresh unchanged-state read; and navigation during pending approval → fresh state before any new request. The person should operate approvals in that experiment. Hronaut's pause blocks new commands but does not undo dispatched work; application approval and downstream authorization remain separate (documented boundary).

Which OS and coding-agent client would you use? And by navigation, do you mean an in-app scope/route change, a full reload, or another document? That will let us choose one reproducible first run rather than imply all three are covered. No RCIP bridge has been built or tested here.

Hronaut maintainer reply, prepared with AI assistance and automated browser checks.

[rohit-binaried]

Thanks for running those checks and documenting the boundaries clearly. For the first experiment, I’d use Windows with Codex and keep it to browser UI interaction. By navigation, I mean an in-app scope or route change such as Todos → Profile, rather than a reload or cross-document transition.

My Codex workspace is container-backed, so I’ll first verify access to Hronaut’s Windows loopback endpoint; otherwise I’ll use a Windows-local Codex session. An RCIP bridge would remain a separate follow-on experiment.

Drafted with AI assistance.

[Hronom]

Yes, that is a good first boundary: Windows + Codex, browser UI only, and an in-app Todos → Profile route change. Keeping the RCIP bridge separate should make the result much easier to interpret.

For the Hronaut side, use the current public v2.4.25 Windows build and the Codex setup snippet from Hronaut Home. Hronaut exposes a local Streamable HTTP MCP endpoint, normally http://127.0.0.1:47812/mcp, and the Windows binary is currently unsigned, so verify the release hashes/attestation if SmartScreen warns. Do not paste or publish an MCP token.

One important boundary: Hronaut is loopback-only. A container-backed Codex session cannot be assumed to reach the Windows host's 127.0.0.1; if the harmless health/tools check cannot reach the endpoint, use a Windows-local Codex session rather than changing Hronaut to listen publicly. The product itself does not provide a hosted browser or container-to-host relay.

Suggested public/synthetic sequence:

1. Start Hronaut and connect Codex using the generated client instructions; record the Hronaut version, Windows build, Codex mode, and whether tools/list plus a harmless browser-workspace read succeed.
2. Use a fresh isolated workspace and the account-free RCIP demo or another disposable fixture. Do not use credentials, private RCIP data, private URLs, funded wallets, or production records.
3. Change a Todos value manually in the page, then ask Codex for a fresh read and compare the visible state with the application state.
4. Request the proposed application write, decline it manually, then perform a fresh read. Record whether the state is unchanged.
5. Start another proposed write, switch Todos → Profile while approval is pending, and record the application result. Return to Todos and perform a fresh read before any retry.

Please label each result passed, failed, not attempted, or unknown. Hronaut’s pause rejects new MCP commands but does not undo an action already dispatched; the application’s approval and authorization rules remain the authoritative boundary. This first run is browser/UI interaction only—no RCIP bridge, LLM-compatibility claim, or full document-navigation claim.

I maintain Hronaut; this reply was prepared with AI assistance. A public, sanitized result is welcome, including a failed setup, but please omit tokens, credentials, private page data, and personal browser-session details.

[Hronom]

Hi Rohit — yes, that would be a useful first owned-app QA case. Let’s keep the first pass narrow and browser-UI-only:

• Windows + Codex, Hronaut v2.4.29, one named workspace and one tab
• account-free React fixture with a visible value change
• agent reads the value, proposes a write, and the human declines it
• verify the value remains unchanged
• while approval is pending, navigate from Todos to Profile and verify the target route plus the pending decision state
• finish with a fresh read-back of the route, value, and decision outcome

Please keep the RCIP bridge separate from this first run. If the container-backed Codex session cannot reach the Windows loopback endpoint, the Windows-local Codex fallback is the right boundary. Use only disposable/public fixture data; no credentials, private pages, funded wallets, or external side effects. A public fixture link and a sanitized receipt are enough for comparison. Hronaut-maintainer and AI-assistance disclosure in the report would be appreciated.