Known Issues
This page tracks known limitations and issues across Holon surfaces. Items graduate off this page when resolved.
Runtime
| Issue | Severity | Affected Versions | Workaround | Reference |
|---|---|---|---|---|
| Remote transport is still only a bounded proof surface — Phase 8F adds local operator diagnostics for startup posture, per-connection blocked reasons, and shutdown totals, but the listener is still plain TCP bearer auth without TLS, with no WebSocket transport, async serving, or production internet-facing server posture | Blocking for full remote use | 0.1.0 | Use loopback mode by default, use explicit non-loopback only for controlled local network testing, and treat remote JSONL access as status, inspection, and durable replay only | runtime/README.md |
| Remote transport auth is transport-local proof only — remote clients need configured bearer auth before read-only access in either loopback or explicit non-loopback mode, but there is still no user identity provider, OAuth flow, token issuance or rotation, remote writes, provider execution, cancellation, or concurrent multi-client coordinator | Medium | 0.1.0 | Use ClientKind::Remote only for runtime/session inspection and durable event replay continuity, and configure one transport-local bearer token for that session when testing remote JSONL access over transport stdio or transport tcp-readonly | Phase 8B / Phase 8E |
| Single-connection FIFO transport per session — TCP can now serve a bounded sequential number of connections, but there are still no concurrent connections | Low | 0.1.0 | Desktop app uses direct in-process calls; CLI runs as single process | — |
| Run admission is plan-scoped (not step-scoped) — only one active run per plan | Low | 0.1.0 | Run one plan at a time | run/execute-safe contract |
| No in-flight run cancellation — cancel only affects queued runs | Medium | 0.1.0 | Cancel before runs enter active state | run/cancel contract |
| Plan revision is linear and latest-plan-only | Medium | 0.1.0 | Plan compare supports only direct parent-child | plan/compare contract |
| Elegy v2 import is state-only — no external Elegy invocation | Medium | 0.1.0 | Import Elegy JSON manually; no file discovery | skill-definition import |
| Skill source registration is inert descriptor only — no file watching, no MCP connection | Medium | 0.1.0 | Register sources manually; capabilities are metadata only | skill-source register |
run/execute-safe only supports no-op, dry-run, and a small fixed built-in-safe inspection set | Medium | 0.1.0 | Use only for inspection and side-effect-free execution | run/execute-safe contract |
Overlarge transport frames return overloaded and continue — no backpressure queue | Low | 0.1.0 | Keep JSON frames under the bounded ingress limit | transport/status |
| Schema fixtures are structural protocol artifacts only — no generated TypeScript or OpenAPI clients | Medium | 0.1.0 | Use holon-runtime-client crate or hand-write types | schema_fixtures |
Bridge bindings, bridge sessions, and bridge/readiness are implemented as contract and readiness state only — api is the only currently executable bridge lane, while browser, plugin, desktop UIA, and fallback lanes are represented but explicitly blocked until their lane hosts are implemented | Medium | 0.1.0 | Treat bridge state as governance and target or session readiness evidence for now; keep live execution scoped to the existing API adapter floor and use workflow-step readiness for operation-specific compatibility | Bridge contract / piloting roadmap |
Provider bridge health probing is available through the runtime API (probe_bridge_health, probe_named_bridge_health) but is not yet surfaced in the desktop provider UI as a live status indicator separate from API-key health. The Moon Bridge (http://127.0.0.1:38440) is the first registered known bridge with default health URL /health. | Low | 0.1.0 | Use the runtime API directly for bridge health checks. The provider catalog and status results now include bridgeKind and bridgeHealth fields for inspection. | Provider bridge architecture |
| Durable session artifacts currently cover create/list plus deterministic host-owned outcome synthesis only — there is no model summarizer, artifact conflict resolution, background compaction, cross-device sync, or first-class desktop artifact inspector UI yet | Medium | 0.1.0 | Treat retained artifacts as bounded host-owned context and inspect them through runtime or session-detail debug surfaces rather than expecting autonomous memory management or polished renderer projection | Session artifact Phase 3 MVP |
Subprocess sandbox metadata is advisory only — the current runtime subprocess path enforces validation, policy, approvals, output bounds, and timeouts, but SandboxConfig still only passes HOLON_SANDBOX_* environment signals and does not yet claim OS-level filesystem or network confinement | Medium | 0.1.0 | Treat subprocess tools as runtime-governed but not OS-confined, keep trusted execution scope narrow, and rely on runtime policy, approval, and evidence rather than assuming host isolation | Desktop Runtime Integration; earlier sandbox planning |
Desktop
| Issue | Severity | Affected Versions | Workaround | Reference |
|---|---|---|---|---|
| Provider OAuth is only partially implemented — desktop Gemini loopback PKCE exists, but broader provider OAuth parity does not | Medium | 0.1.0 | Use API key providers by default; Gemini OAuth is available in the desktop shell where configured | Provider runtime/auth surfaces |
Workspace chat currently has two execution modes: a role-routed provider-backed live-model path and a bounded runtime-tool fallback. Provider-backed live chat now uses a host-authored instruction bundle plus bounded retained session artifacts, and the live-model path can execute a narrow Responses API tool loop over the current workspace-chat allowlist of built-in model-callable runtime tools. Direct completions providers now have first-class tool-call support via native chat/completions tool calling, reasoning metadata extraction, and refusal handling. A Responses-bridge provider lane (e.g. DeepSeek via Moon Bridge at http://127.0.0.1:38440/v1/responses) exposes Codex-like Responses semantics through a local forwarding layer. It still does not provide streaming, broad tool orchestration beyond the allowlist, structured model-output enforcement for clarification/approval/unknown/blocked/failure classes, or full bridge health availability checking in the desktop UI. | Medium | 0.1.0 | Treat command terminalStatus, persisted session detail, durable retained artifacts, durable system error turns, and emitted tool-call events as authoritative host state. Instruction framing, retained context, role-aware routing, and the narrow provider tool loop improve grounding, but outcome truth still comes from host-owned execution and persisted results rather than parsed provider reply text alone. | AI Contract And Conformance Boundaries; Desktop chat live-model + runtime-tool slice |
Role-aware model routing and bounded child-lane execution are only partially implemented. main-chat now returns authoritative requested and effective route truth with explicit blocked states for missing configured providers, desktop send-message can execute one sequential read-only summary-scout child lane with durable orchestration summary truth, and desktop cancel now cooperatively stops the active send at host-owned phase boundaries with truthful TurnCancelled plus child terminal events. Preview results are still not durable audit history, parent currentModelSelection intentionally reflects the parent main-chat route instead of the child route, and hard-aborting an in-flight provider request, broader role lanes, budgets, reasoning controls, cost truth, and parallel child execution remain absent. | Medium | 0.1.0 | Use send-message routing results, persisted session orchestrationSummary, currentModelSelection, durable turn outcomes, and emitted terminal events as execution truth. Treat preview routing as inspection only, and treat provider-request abort as best-effort future work rather than current behavior. | AI Contract And Conformance Boundaries; Phase 4A, Phase 6A, and Phase 7A desktop routing or orchestration or cancellation slice |
| Desktop observation capture depends on an external umbrella Elegy CLI resolved from desktop config or approved environment fallbacks, while bundled package executables still have separate readiness gaps | Low | 0.1.0 | Configure tools.elegy.executablePath, ELEGY_CLI_PATH, or the dev-only ELEGY_REPO_ROOT fallback before using Settings -> Observation capture. Use the Observation settings diagnostics to inspect pinned elegy-memory and elegy-planning executable readiness, published receipt-backed paths, version mismatches, and recovery guidance. Observation consent and lease state stay runtime-backed even when the CLI is unavailable. The current bootstrap flow publishes elegy-memory as a wrapper surface but does not yet publish elegy-planning; runtime live subprocess execution still resolves package executables by raw name instead of a receipt-backed resolver. Runtime now supports deterministic workflow execution for capability, frozen-tool dry-run, adapter-operation dry-run plus one fail-closed live API adapter lane in workflow-run/execute-ready, human-gate, wait-timer, branch-condition, and bounded ai-step nodes, including live responses-compatible API-key ai-step dispatch. Governed target descriptors and surface maps now gate the API lane on health, newest surface drift, surface-map presence, target kind, and declared operation compatibility before dispatch. | Desktop observation capture surface |
Workflow Runtime
| Issue | Severity | Affected Versions | Workaround | Reference |
|---|---|---|---|---|
Live ai-step dispatch currently supports only providers with an implemented responses-compatible API-key wire path in the runtime defaults; deterministic provider_result mode remains the fallback/test path | Medium | 0.1.0 | Use provider_result for fully local deterministic runs, or configure a runtime-supported responses-compatible provider plus provider secret for live dispatch. Providers without a default live wire path require explicit node-level overrides and are still compatibility-best-effort. | workflow-run/execute-ready runtime path |
Live ai-step dispatch does not yet provide streaming, provider-managed orchestration, or full non-responses native provider parity for structured-output JSON extraction | Medium | 0.1.0 | Keep live ai-step usage bounded to non-streaming calls and use catalog defaults or explicit node-level base_url/wire_api overrides. Completions providers can now return text, reasoning metadata, and native chat tool calls through the first-class completions path, and Responses-bridge providers (such as DeepSeek via Moon Bridge) use the /v1/responses forwarding layer for Codex-like Responses semantics. | AI Contract And Conformance Boundaries; Workflow runtime roadmap |
adapter-operation workflow nodes now support one bounded live API lane backed by adapter-sourced catalog entries, governed target descriptors, and required newest surface-map state, but browser, desktop UIA, vision, raw-input, and broader side-effectful adapter lanes remain unimplemented | Medium | 0.1.0 | Keep live adapter usage scoped to the API lane's non-streaming JSON HTTP path with stable base URLs, path/query binding, and JSON responses. Expect explicit unhealthy targets, missing surface maps, non-API target kinds, declared-operation mismatches, drifted or blocked surface maps, plus explicit workflow-workspace versus target-workspace mismatches to fail closed before dispatch. Live API execution now supports bounded bearer-style auth resolved from secret_ref or session_ref bindings through the existing secret store; this does not imply browser sessions, desktop automation, or a broader session broker. | Workflow runtime roadmap |
Workflow-driven frozen-tool live execution currently supports validated workspace-scoped script-artifact proposals and artifact-ready workspace-scoped rust-code-tool proposals, but broader frozen-tool kinds, fallback, repair, regeneration, and demotion analytics remain unimplemented | Medium | 0.1.0 | Keep live frozen-tool reuse scoped to the current script-artifact plus managed Rust CLI floor. Other future implementation kinds should remain on the bounded review or dry-run path until a deliberate enhancement slice widens execution support. | Workflow runtime roadmap |
rust-code-tool requires a filesystem-backed runtime database and local cargo; Runtime::in_memory() and non-ready Cargo dependency posture are not supported for build/test/live execution | Medium | 0.1.0 | Use a filesystem-backed runtime DB and ensure cargo is present and recorded as ready before building or testing managed Rust tools. | rust-code-tool/* runtime path |
rust-code-tool dependency approval is intentionally narrow: only curated catalog entries with exact approved versions and features are accepted | Low | 0.1.0 | Keep managed Rust tools within the current curated dependency catalog, or treat broader dependency support as a future enhancement slice rather than an ad hoc exception. | Rust code tool policy floor |
CLI
| Issue | Severity | Affected Versions | Workaround | Reference |
|---|---|---|---|---|
| Console command is a scaffold — never waits on stdin by default | Low | 0.1.0 | Use --once for single prompt; use transport stdio for interactive sessions | console --once |
| CLI and desktop cannot operate on the same SQLite database simultaneously | Medium | 0.1.0 | Close one before opening the other; SQLite single-writer constraint | Architecture docs |