Good First Issues in Python

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

Description FAISSIndex.save() currently persists only the underlying FAISS index, while the associated vector_ids and metadata are kept only in memory. As a result, loading a previously saved FAISS index does not restore the logical IDs and metadata associated with the stored vectors. Reproduction Create a FAISS store. Add vectors with IDs and metadata. Save the index. Start a new process and load the saved index. Inspect the store. The loaded index can contain the physical vectors, but vector_ids and metadata are not restored. This can cause: count() to report an incorrect value. get_vector(id) / scan_vectors() to behave incorrectly. Existing IDs to be invisible to duplicate detection. Re-running a migration after restarting the process to add duplicate physical vectors. Expected behavior Saving and loading a FAISS store should preserve the complete logical state associated with the index: vector IDs metadata underlying FAISS vectors/index Suggested fix Persist vector_ids and me

Description The LLM wrappers are not completely consistent in how generate_typed() is exposed and typed across providers. The underlying BaseProvider already provides typed-generation functionality, but the public wrapper APIs do not all present it with the same explicit interface/documentation. Suggested improvement Review the existing LLM wrappers and standardize: generate_typed() availability method signatures type annotations documentation test coverage This would make the public semantica.llms API more predictable regardless of provider. Note This appears to be broader API consistency work rather than a blocker specific to PR #1262. Priority Non-blocking / follow-up.

Description Some LLM provider wrappers annotate generate_structured() as returning a Dict, while the underlying structured parsing behavior can produce broader JSON-compatible structures, including a top-level list. This makes the public type annotations narrower than the actual supported runtime result. Suggested improvement Review the return annotations across the LLM providers and align them with the actual structured-output contract. In particular, consider using a broader JSON-compatible return type where both objects and arrays are supported. Why This would make the public API typing more accurate and consistent across providers. Priority Non-blocking / follow-up.

Description The legacy Gemini SDK path can create a new GenerativeModel instance when a different model is supplied for an individual request. This is functionally acceptable, but repeated requests using the same alternate model can result in unnecessary model-object creation. Suggested improvement Consider caching/reusing model instances per model name where appropriate, while keeping credential isolation and provider-instance behavior safe. For example, a provider could maintain model instances keyed by model name rather than recreating the same model object for every request. Note This is primarily a performance/implementation improvement and does not block the current provider-wrapper PR. Priority Non-blocking / follow-up.

Description The Gemini provider handles the optional per-call model argument inconsistently between generate() and generate_structured(). A caller passing: model="some-model" should get consistent model-selection behavior regardless of which generation method they use. Expected behavior generate(model=...) and generate_structured(model=...) should both honor the per-call model override consistently across the supported Gemini SDK paths. Why Inconsistent model selection can be surprising for callers using the same provider through different generation methods. Suggested improvement Align the model-selection logic between generate() and generate_structured() and add regression tests covering per-call model overrides. Priority Non-blocking / follow-up.

Problem Statement There's a Dockerfile for the Knowledge Explorer app and dev docker-compose files in the repo, but there's no published, versioned image on a registry. Anyone who wants to run Semantica in a container today has to clone the repo and build it themselves — there's no docker pull path, which is the default first step for a lot of infra/platform teams evaluating a new tool before they touch pip install. Proposed Solution Publish official, versioned images to a registry (GHCR under ghcr.io/semantica-agi/semantica, and/or Docker Hub) as part of the release pipeline, tagged to match PyPI releases: docker pull ghcr.io/semantica-agi/semantica:0.6.7 docker pull ghcr.io/semantica-agi/semantica:latest docker run -p 8000:8000 ghcr.io/semantica-agi/semantica:latest Concretely: Add a docker-build-push.yml workflow (or extend .github/workflows/release.yml) that builds and pushes on tag release, alongside the existing PyPI publish step Tag images with the exact semver (0.6.7), plus

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.

What happens The OSV advisory scan (uv.lock) step in .github/workflows/security-scan.yml runs: uv export --frozen --format requirements-txt --all-extras > /tmp/uv-req-full.txt --all-extras cannot be satisfied, because pyproject.toml declares extras that conflict: [[{'extra': 'antigravity'}, {'extra': 'cwsandbox'}], [{'extra': 'antigravity'}, {'extra': 'modal'}], [{'extra': 'antigravity'}, {'extra': 'databricks'}], [{'group': 'lint'}, {'extra': 'antigravity'}]] so uv exits 2: error: Extras `antigravity` and `cwsandbox` are incompatible with the declared conflicts: {`omnigent[antigravity]`, `omnigent[cwsandbox]`} Why it matters The step only fires when uv.lock is in the changeset, so it is invisible until a PR touches the lockfile, and then it always fails. No advisory is ever evaluated: the export dies before pip-audit runs, so the scan blocks PRs without providing the check it exists to provide. For a fork PR the effect is larger. A failed Security Scan fails the Security

What happens Attach a file to a message addressed to the Slack or Discord bot and ask the agent to work with it. The agent never sees it — it answers as though only the text was sent. Why Neither bot reads inbound attachments. handle_message takes message.content and nothing else; message.attachments is dropped on the floor. This is not a permissions or intent problem. Discord's message_content intent, which the bot already requires, covers "message content, attachments, embeds and components", so the data is already in the payload the bot receives. Slack likewise delivers a files array on the message event. Both bots simply ignore it. The only file handling either bot has today is the reverse direction: announcing a file the agent produced (format_output_file, from response.output_file.done). What it would take The server already accepts uploads: POST /v1/sessions/{session_id}/resources/files GET /v1/sessions/{session_id}/resources/files/{file_id}/content So the work is the plumbi

Summary In RepoWise 0.46.0, repowise update --full --dry-run enters the full-upgrade branch and invokes upgrade_to_full. The dry-run flag is not checked or passed through on that branch. Reproduction Initialize a repository with a fast index. Snapshot the .repowise database, state, and configuration hashes. Run repowise update --full --dry-run. Observe that the command announces and starts the full upgrade instead of returning a read-only plan. Index state can change before cancellation. The control-flow cause is in packages/cli/src/repowise/cli/commands/update_cmd/command.py: the if full branch dispatches upgrade_to_full(...) and returns before the normal dry-run guard later in run_update. Expected behavior Dry-run must print the planned full upgrade and estimate without invoking the upgrade worker, provider calls, persistence, locks, or state/config writes. Actual behavior The upgrade worker runs. This can backfill the Git tier, generate documentation, consume provider compute, alt

Description Kimi Code supports custom OpenAI-compatible providers such as OpenRouter. A Kimi installation configured this way works normally from the command line, but Omnigent reports the Kimi harness as unavailable. The readiness check in omnigent/onboarding/kimi_auth.py only accepts providers identified as Kimi or Moonshot by provider type or hostname. An OpenRouter provider is therefore rejected even when it has a valid API key and is the configured default provider. This causes the host to advertise: kimi-native: false As a result, Kimi cannot be selected in the Omnigent UI without patching the readiness check. Issue #5126 and PR #5138 added support for direct Kimi/Moonshot API-key authentication. They do not cover custom providers supported by Kimi Code itself. Steps to reproduce Configure Kimi Code to use OpenRouter: toml default_model = "openrouter/moonshotai/kimi-k3" [providers.openrouter] type = "openai" base_url = "https://openrouter.ai/api/v1" api_key = "" Confirm Kimi w

Follow-up to #174, which landed its minimal half in #176: web/-only pull requests now get a syntax check (node --check web/app.js). That catches parse errors and nothing else. render_gui.py already exists as a real GUI check — headless-Chromium screenshots that fail on JS runtime errors, element overflow, horizontal scroll, or missing rows. Wired into the same workflow it would gate the class of breakage the syntax check cannot see: code that parses and then breaks the page. What #174 established and what it did not: node --check was verified on the runner. render_gui.py inside a GitHub Actions runner was not — locally it needs pip install -r requirements.txt plus playwright install chromium, and #174 estimated ~1–2 minutes of job time. Whether it runs headless in CI at all, and what it actually costs, is the open question — so this is a problem statement, not a recipe. First step for whoever takes it: get render_gui.py to produce its screenshots in a runner on a scratch branch

Found while re-reviewing #154's counting paths. It exists on main independent of that PR, in both front-ends, so it gets its own issue per the usual scope rule. The accounting A run finishes only when every link is counted. In the CLI: mark_done() bumps n_done and sets all_done once n_done >= len(urls) (moon_cli.py:95-98); each browser_worker exits only on all_done.is_set() and q.empty() (moon_cli.py:183); run() gathers those workers (moon_cli.py:292). The engine is the same shape: mark_done at moon_engine.py:355-358, the worker's exit check at moon_engine.py:216. The dropped path A stall-killed download is re-queued for re-extraction with the same record (moon_cli.py:163-167; engine equivalent in _do_dl), and on pickup the entry is flagged is_re = rec.stall_kills > 0 (moon_cli.py:196, moon_engine.py:231). If that re-extraction then fails: the retry branch excludes it — not is_re at moon_cli.py:260 and moon_engine.py:316; the fail branch excludes it too — not is_re at moon_cli.py:

Under which category would you file this issue? Airflow Core Apache Airflow version 3.2.2 What happened and how to reproduce it? When running GCSToGCSOperator with move_object=True, if a task fails after the file has been successfully copied and deleted from the source bucket (e.g., not acknowledge due to network issue), a task retry will attempt to delete the source object again. Because the object was already deleted in the previous run, the hook.delete() call raises a google.api_core.exceptions.NotFound (404) error, causing the task retry to fail completely rather than succeeding idempotently. Logs of error: [2026-08-28 19:07:45] INFO - Object application/interface/myfile.xml in bucket professional-bucket-europe-west1-in rewritten to object ... [2026-08-28 19:07:45] INFO - Blob application/interface/myfile.xml deleted. [2026-08-28 19:07:45] INFO - Executing copy of ... ... [2026-08-28 19:07:55] WARNING - Blob application/interface/myfile.xml in bucket professional-bucket-europe-west

Since recently, Carto started to require an API key to use map tiles, thus showing watermark on any requests without one. API key should append to the end of request of every tile (e.g. https://basemaps.cartocdn.com/rastertiles/voyager/{z}/{x}/{y}.png?key=YOUR_KEY).

Maintainer's note, not a work item — nothing here needs a PR. I wrote a paper about the evidence layer this repository ships: "Receipts, Not Logs: Offline-Verifiable Run Records for LLM Agent Orchestration" The short version: agent frameworks produce logs, and a log proves only what the operator says happened. Bernstein takes the opposite bet — the coordination loop is deterministic Python with no model in the scheduling path, every run appends to a hash-chained journal, and a finished run collapses into one Ed25519-signed receipt that anyone verifies offline from the file alone. The paper states the trust model, what it deliberately does not protect against, and an adversary matrix measured on real runs of this repository's own backlog. It is not on arXiv yet, for two reasons: the same journal now also projects into a TRACE Trust Record, and that section has to match the spec as it currently stands (#4740 and #4743 are that alignment); and I want another week of production runs be

Summary Private-training rounds need explicit enrollment, update-submission, aggregation, and evaluation windows. Ambiguous or overlapping deadlines make lifecycle state and air-gapped participation nondeterministic. Scope Define an immutable UTC schedule with strictly ordered phase boundaries, optional maximum durations, and deterministic serialization. Resolve the active or next phase from a caller-injected timestamp without reading the system clock. Acceptance criteria Before-start, exact-boundary, active-phase, and after-finish cases resolve predictably for every phase. Naive timestamps, non-UTC offsets, reversed or equal boundaries, booleans, and excessive durations fail with field-only errors. The schedule contains no site identity, patient count, local metric, or network endpoint. .venv/bin/python -m pytest tests/unit/training/test_federated_schedule.py -q passes. Out of scope Network coordination, client notification, retries, or selecting the round lifecycle state. Extend

Summary A client capability envelope and an immutable round manifest are useful only if compatibility is checked before enrollment. The comparison must explain incompatibility without exposing client identity, exact hardware inventory, or local data characteristics. Scope Compare protocol versions, training backend, model and adapter format, quantization support, declared resource class, deterministic-kernel support, privacy mechanism, and secure-aggregation mode. Return compatible, review-required, or incompatible with stable field-level reason codes and a metadata-only deterministic report. Acceptance criteria Exact match, supported version range, insufficient resources, unsupported privacy mode, adapter mismatch, and unknown requirement cases have table-driven tests. Unknown mandatory requirements fail closed; optional capability differences are distinguished from hard incompatibilities. Reports exclude client IDs, site names, hardware serials, paths, endpoints, patient counts, l

Summary Several multimodal modules compute SHA-256 independently, and callers need a shared streaming helper that does not load large PDFs, images, DICOM objects, or audio files into memory. Scope Hash bytes and binary streams in bounded chunks, returning the SHA-256 digest and byte count with an optional hard maximum. Preserve a seekable stream's position, never close caller-owned streams, and keep errors free of paths, filenames, and byte content. Acceptance criteria Bytes, seekable streams, non-seekable streams, empty input, and multi-chunk input match hashlib.sha256 reference digests. Exceeding the configured maximum fails before unbounded reading and reports only the limit category and numeric counts. Tests verify position restoration for seekable streams, no implicit close, and bounded read request sizes. .venv/bin/python -m pytest tests/unit/multimodal/test_digest.py -q passes. Out of scope Cryptographic signatures, content-addressed storage, or opening filesystem paths. Ma

Summary The new asset manifest, media-type detector, modality profiles, resource limits, and streaming digest checks need one pre-decode entry point. Without a common report, each future VLM, OCR, DICOM, waveform, and audio provider will assemble different safety behavior. Scope Orchestrate manifest validation, declared-versus-detected media type, modality-specific fields, digest matching, and resource limits into a single accept-or-abstain report. Return deterministic findings, reason codes, schema versions, numeric metadata, and digests only; never open a heavy decoder or copy source content into the report. Acceptance criteria Synthetic happy-path examples for image, PDF, DICOM, and audio are accepted with byte-stable JSON. Media mismatch, malformed manifest, digest mismatch, insufficient metadata, and every resource-limit class produce ordered fail-closed findings. A sentinel test proves filenames, paths, OCR text, transcripts, DICOM values, credentials, and raw prefix bytes do

Summary A generic asset manifest can be structurally valid while still omitting the metadata needed to preflight its declared modality. Image dimensions, PDF page counts, DICOM frame geometry, and audio duration need explicit cross-field rules. Scope Add versioned image, PDF, DICOM, and audio manifest profiles that declare required, optional, and inapplicable metadata fields. Validate a privacy-safe asset manifest into deterministic field-only findings without opening or decoding the asset. Acceptance criteria Image width/height, PDF page count, DICOM frame count plus dimensions, and audio duration requirements have table-driven valid and invalid tests. Inapplicable fields, missing required fields, zero values, booleans, and non-finite numeric values produce stable categorical findings. Results contain only field names and reason codes, never source paths, embedded metadata, or media content. .venv/bin/python -m pytest tests/unit/multimodal/test_manifest_profiles.py -q passes. Out

Summary Image, document, waveform, and audio paths need a shared way to explain why processing stopped. Free-form messages are hard to evaluate and can accidentally contain OCR text, DICOM metadata, transcripts, or paths. Scope Define typed preflight, decode, inference, and post-process abstention stages with stable reason codes for unsupported media, malformed media, resource limits, low quality, PHI uncertainty, speaker uncertainty, temporal instability, and unavailable providers. Provide deterministic metadata-only serialization and strict validation without a free-text message field. Acceptance criteria Every documented stage and reason code round-trips with stable JSON output. Invalid stage-reason combinations and unknown values fail without echoing submitted content. The serialized schema cannot contain OCR text, transcripts, pixel data, DICOM values, paths, URLs, or model prompts. .venv/bin/python -m pytest tests/unit/multimodal/test_abstention.py -q passes. Out of scope De

Summary The v3.1 safety contracts need a shared offline fixture pack so contributors can test allow, denial, abstention, and reviewer-handoff behavior without constructing traces ad hoc or using real clinical content. Scope Add a versioned JSONL fixture manifest and import-light loader for synthetic governed-agent trace cases. Cover read-only allow, minimum-data projection, missing capability, purpose mismatch, expired consent, human review, and bounded failure scenarios using opaque identifiers and digests only. Acceptance criteria Every declared case loads deterministically and is classified by a stable expected outcome and reason code. Fixture validation rejects unknown fields, duplicate case IDs, malformed digests, and undeclared expected outcomes with PHI-safe errors. A coverage assertion keeps focused tests synchronized with all fixture case IDs, and the committed fixture contains no names, chart text, credentials, or tool arguments. .venv/bin/python -m pytest tests/unit/eval/

Summary Reviewers and tests need to compare policy decisions across tools and purposes without inspecting tool arguments or clinical outputs. There is no compact matrix artifact for this metadata-only view. Scope Model matrix rows using policy version, capability ID, purpose ID, tool ID, outcome reason code, and reviewer-required flag. Render deterministic JSON and Markdown with stable row ordering and duplicate-key validation. Acceptance criteria Empty, allow, deny, abstain, and review-required synthetic matrices render byte-stably across repeated runs. Duplicate decision keys and unknown outcome codes fail closed without echoing submitted values. A sentinel test proves prompts, arguments, outputs, evidence text, bearer values, and filesystem paths cannot appear in the artifact schema. .venv/bin/python -m pytest tests/unit/agent/test_policy_matrix.py -q passes. Out of scope Evaluating policies, granting capabilities, or executing tools. A reviewer UI or persistent audit database.

The dashboard is a single-file, dark-mode, chart-heavy page, and accessibility got no dedicated pass. Current state in static/dashboard.html: 40 aria-label attributes vs 4 tabindex, Chart.js canvases with no text alternative, and the tab/filter controls are mouse-driven. Nothing is broken in an aggressive way — but a keyboard-only or screen-reader user has a rough ride. Suggested scope (take any section — each is independently shippable) Keyboard reachability: tab order through the sidebar tabs, range filters and card actions; visible focus styles in the dark theme. Landmarks & roles: role on the data tables, labels on icon-only buttons (the inline-SVG header icons in particular). Charts: a short text summary per chart (peak/last value) so the sparklines aren't canvas-only. Colour: the status colours (green/amber/red dots) shouldn't be the only channel — a text state is already rendered next to most of them, so verify coverage. A PR that takes one section with a short "what I c

The security model is real and partly tested — tests/test_hardening.py covers the per-host posture checks, docker-compose.readonly.yml exists for a read-only setup, the MCP server documents its read-only guardrail, and API-key auth for the API surface lives in backend/auth.py. But the documentation is scattered: one paragraph in features.md, a "Security model" section in how-it-works.md (the no-login design decision, the read-write Docker/D-Bus sockets, the "keep it behind your LAN" guidance), and nothing else. There's no dedicated page, and the nav (mkdocs.yml) has no entry for it. For a self-hosted tool that SSHes into your fleet, that's the page a newcomer looks for first. Suggested scope A website/security.md page that gathers what's already true and documented in one place, and adds what's missing: the no-login design decision and why (already in how-it-works.md), the socket/D-Bus privileges and the write-action flags that reduce them, API-key auth for the API/MCP surface, the