Claude Code
The Claude Code adapter drives the claude CLI through the Claude Agent
SDK, with its local hook stream layered on top. It is the most
fully-wired runtime in Helmora today, and the one most other adapters are
measured against.
Requirements
Section titled “Requirements”The claude executable on the bridge machine’s PATH, plus an existing
Claude login or an API key. The adapter detects install and auth posture
and tells you which is missing; signing in happens in your own terminal,
not in the app.
Claude Code registers one agent per folder, because its session store is folder-scoped. Adding a second project means a second registration on the same bridge.
What the adapter supports
Section titled “What the adapter supports”Persistent sessions. The adapter keeps a live SDK session rather than launching a fresh process per turn, which is what makes mid-turn steering and immediate model switches possible.
Streaming. Assistant text, reasoning, tool calls, and tool output stream into the transcript as they happen, with tool arguments and results rendered inline rather than collapsed into an opaque blob.
Tool approvals. When Claude Code asks for permission to run something, the request surfaces as a card in the app. Approve or deny it from your phone and the running turn continues.
Structured questions. Claude Code’s ask-the-user mechanism renders as a real choice card with the model’s own options, in any permission mode. Pending questions survive a reconnect — reopening the session rebuilds the answerable card rather than stranding the turn.
Diffs and plans. File edits render as diffs. Plan-mode turns render as plans you can read before approving the work.
Runtime controls. Model, effort, and permission mode can be changed without starting a new session. Model changes apply from the next response, permission-mode changes can take effect within the active turn. Claude Code additionally exposes its workflow-orchestration and fast-mode toggles as first-class controls, and extended thinking is presented separately from effort.
Usage windows. The session gauge shows context consumption; tapping it shows plan usage for your Claude account. Compaction is available manually and fires automatically near the threshold, with a marker in the transcript so you can see where it happened.
Account profiles. If you keep more than one Claude configuration on a machine, Helmora can register them as separate agents and switch between them. Capability discovery is profile-scoped — one profile’s controls are never advertised for another.
Workflows and sub-agents. Sub-agent activity renders as its own grid, and you can drill into a sub-agent’s transcript to see what it actually did. Background tasks appear in the background-task sheet, with a per-row stop while the persistent session is live.
Slash commands and MCP. The composer offers the CLI’s slash-command palette. MCP servers configured for the project are listed and manageable from the Tools panel.
External-session mirroring. Sessions you start directly in the
claude CLI show up in Helmora. A live externally-driven turn is
read-only — the Stop button is deliberately withheld, because the turn
isn’t ours to cancel — and you can take a session over with an explicit
“Continue in Helmora” handoff.
Known boundaries
Section titled “Known boundaries”- Claude Code has no first-class compaction RPC; Helmora compacts through the prompt path. The gauge, marker, and resume behavior are the same as the other runtimes.
- Verbosity control is not exposed.
- Sign-in is detection-only. The app tells you that you need to run
claudelogin in your terminal; it does not run it for you.
Capability differences across runtimes are deliberate. The app only renders controls the active adapter actually declares — see Architecture.