omnigent-ai/omnigent

Problem or use case We run one shared, always-on omnigent-server with many long-lived, persistent hosts registered against it (one per developer workspace, provisioned by an internal platform — think one host per Coder/devcontainer workspace, each corresponding to a specific project/repo checkout). Each workspace exposes a dashboard tile that opens the shared omnigent web UI. Today that tile can only open the generic New Chat screen (/), where the user must manually find and pick their specific workspace's host from what can be a long, growing list of registered hosts. There's no way for the tile's URL to say "open New Chat pre-bound to this host" — the user has to correctly identify their own workspace among potentially dozens of others every time. We looked for an existing mechanism and found: No ?host=<id>//new/:hostId-style route on the New Chat screen (web/src/App.tsx, web/src/shell/NewChatDialog.tsx). The only related mechanism, ?project=<name> on /, only pre-selects a host

Version / pin omnigent CLI 0.10.0 (uv tool install --force "omnigent[tracing,claude-sdk]") Vendored tree pinned at tag v0.10.0, commit 40755dd8dddb07e1eb6e4055d1d9936e184ceb9b Host: macOS (darwin 25.5.0) Why a new issue This corrects and replaces #5103 (closed COMPLETED, no comments). #5103's impact claim was too strong and our later measurement disproved it: it said the claude-sdk lane "cannot export any telemetry at all regardless of how the daemon environment is configured." That is wrong — when the daemon itself is started in the foreground with the telemetry env set, the lane exports fine (claude_code.* events observed with model, token, cost and session identity). This issue states only the still-true, still-open remainder. Still-true claims OMNIGENT_RUNNER_ENV_PASSTHROUGH (omnigent/host/connect.py:581, consumed by _build_runner_env) did not deliver any named variable to a claude-sdk harness process in our probes — neither CLAUDE_CODE_ENABLE_TELEMETRY nor a completely gene

Version / pin omnigent CLI 0.10.0 (uv tool install --force "omnigent[tracing,claude-sdk]") Vendored tree pinned at tag v0.10.0, commit 40755dd8dddb07e1eb6e4055d1d9936e184ceb9b Host: macOS (darwin 25.5.0) Summary omnigent/runtime/telemetry.py ships both halves of W3C trace-context propagation: get_traceparent_env() (:670) to inject, and extract_trace_context() (:723) to extract. But no launch path extracts the dispatching client's incoming TRACEPARENT: the server generates its own conversation trace and propagates that downward. A wrapper that starts a span, sets TRACEPARENT in the environment, and invokes omnigent run ends up with a trace containing only its own spans; every span and event the run produces (runner, harness, harness-CLI telemetry) rides an omnigent-generated trace id. Measured exhibit (0.10.0, claude-sdk harness) One dispatch of ours: the dispatching wrapper's trace 5fed4abf… holds exactly its own 8 spans and nothing else. The same run's claude_code.* events carry o

Version / pin omnigent CLI 0.10.0 (uv tool install --force "omnigent[tracing,claude-sdk]") Vendored tree pinned at tag v0.10.0, commit 40755dd8dddb07e1eb6e4055d1d9936e184ceb9b Host: macOS (darwin 25.5.0) Summary os_env.sandbox.env_passthrough already solves the named half of environment delivery to spawned harnesses: a bundle spec can list env var names, the spec parser validates them (omnigent/inner/os_env.py:230-231), and the direct-mode executors (acp, codex, pi, kimi, goose, hermes, qwen) plus the sandbox spawn allowlist honour them, so the spawned CLI keeps whatever telemetry/config env the runner holds. This works well and we use it. What is missing is the valued half: values that vary per run. A dispatching client cannot set, e.g., OTEL_RESOURCE_ATTRIBUTES=myapp.run.id=<N> on the harness process of the specific run it is dispatching. env_passthrough resolves names from the runner's environment, which is per-daemon; per-run values cannot travel that way, especially when Harness

Problem Desktop users have different expectations for whether Enter sends a message or inserts a newline. The web composer currently provides no preference, while mobile must avoid accidental submission from Enter. Proposed behavior Add a device-local setting that switches desktop submission between Enter and Command/Ctrl+Enter. Apply the choice to existing-session and new-session composers. Keep mobile Enter reserved for inserting a newline. Show the active chords in composer tooltips and the keyboard shortcuts reference. Make General the default Settings section.