Reported issues for bernstein

Pod holds 22 of 185 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to bernstein.

Most discussed

Stream chain-anchored GenAI spans to OpenTelemetry pipelines over OTLP

Problem

Two halves of OpenTelemetry support exist on main and are disconnected.

src/bernstein/core/observability/otel_projection.py produces a deterministic, signed span projection of the run journal (src/bernstein/core/replay/journal.py): span ids derive from journal entry hashes, every span carries bernstein.journal.entry_hash, and the span set is Ed25519 signed. But it is offline only: a CLI in src/bernstein/cli/commands/advanced_cmd.py writes projection.otel.json and records

Read the thread · 2026-07-16 · closed · 9 comments

Partner adapter wave: wrap agent SDKs and new CLI agents behind the conformance gate

Problem / Motivation

Our adapter surface has grown to roughly fifty entries in src/bernstein/adapters/registry.py, but the trust story behind admission is uneven, and that gap is now an operator hazard.

Two concrete facts from our own tree:

Adapters ship without a machine-checkable contract. tests/contract/contracts/ holds only 16 YAML contracts, yet the registry exposes far more adapters. Several agent-SDK and CLI wrappers we already ship - droid.py, opencode.py, kimi.py,

Read the thread · 2026-07-17 · closed · 3 comments

A2A server surface and agent-registry publication for a callable, discoverable node

Problem / Motivation

Bernstein already speaks A2A as a client and emitter, but it is not yet a first-class node that other agents and apps can call into and discover with verifiable provenance. The gap is visible in our own tree:

src/bernstein/core/protocols/a2a/a2a.py opens with a self-assessment noting the /a2a/* routes have "no Bernstein adapter, CLI command, spawner path, or external system" driving them, and the in-memory A2AHandler "is also not persisted, so A2A tasks are

Read the thread · 2026-07-17 · closed · 3 comments

Add a typed activity boundary so any agent modality runs under the deterministic scheduler

Problem

Bernstein's deterministic scheduler is validated for coding agents, but the same control plane generalizes to research, browser, data, and ops agents. Today there is no uniform contract that lets a non-coding agent participate as a replayable step. We should define one typed activity boundary where every agent kind, whatever its modality, returns an artifact plus the hashes needed to replay it, so the scheduler stays deterministic and the agent stays an opaque stochastic activity beh

Read the thread · 2026-07-06 · closed · 3 comments

Implement webhook signature verification for incoming requests

Description

webhook_signatures.py exists but incoming webhook endpoints (/webhooks/github, /webhooks/slack) do not verify request signatures. Add HMAC-SHA256 verification for GitHub webhooks and Slack signing secret verification, with clear error messages on verification failure.

Metadata

Field	Value
Priority	P1
Scope	medium
Complexity	medium
Role	frontend

Implementation Suggestions

Review API routes in `src/bernstein/core/rou

Read the thread · 2026-04-06 · closed · 3 comments

Task context pack: the container contract, deterministic and content-addressed, with no extractors

What

Build the pack container and its contract, with no extractors: an empty pack that is deterministic, content-addressed, bounded, fails open, and is off behind a flag. The four extractors land on top of it as separate slices.

Part of #4522, which describes the task context pack: a deterministic, content-addressed bundle the orchestrator assembles before spawn and hands to the agent.

This slice is the foundation the other three depend on, so it is worth landing first even though on its o

Read the thread · 2026-08-27 · closed · 2 comments

MCP bridge spec spawns bernstein.mcp.server, which has no main guard: bridge silently never starts

Summary

The MCP bridge spec injected into every agent spawn points at python -m bernstein.mcp.server — a module that has no __main__ guard. Importing it does nothing and exits 0 silently. The real stdio entrypoint is the package: python -m bernstein.mcp (bernstein/mcp/__main__.py → run_stdio()).

Result: every agent's bernstein MCP server reports "failed to start", agents never get the bridge tools (bernstein_post_message, bernstein_claim, bernstein_complete, …), and an

Read the thread · 2026-08-22 · closed · 2 comments

fix(mcp): serverInfo reports the MCP SDK version instead of the bernstein version

What happens

Every MCP client that completes an initialize handshake with the bernstein server is told the server's version is 1.28.1. That is the version of the mcp Python SDK, not of bernstein, which is 3.9.0.

serverInfo: {"name": "bernstein", "version": "1.28.1"}

Observed on a live stdio handshake against bernstein mcp.

Why

src/bernstein/mcp/server.py:1265 constructs the server as:

mcp: FastMCP[None] = FastMCP(name, instructions=_SERVER_INSTRUCTIONS)

[Read the thread](https://github.com/sipyourdrink-ltd/bernstein/issues/3109) · 2026-07-25 · closed · 2 comments

## Most recent

### The deadlock cycle breaker runs every tick against a wait-for graph nothing ever fills

## Problem

The cycle breaker is implemented end to end — `detect_deadlocks()` builds the wait-for graph, finds cycles, and releases the oldest lock in the cycle (`loop_detector.py:257-314`, victim rule at `385-411`, release wired at `agent_lifecycle.py:2548-2555`) — and it runs every tick. But `record_lock_wait()` has no production caller: `_check_file_overlap` (`orchestrator.py:4810-4845`) sees every conflict and defers the batch without recording the wait. `docs/architecture/deadlock-detectio

[Read the thread](https://github.com/sipyourdrink-ltd/bernstein/issues/4673) · 2026-08-27 · closed · 0 comments

### Trust Record emitter: run journal to signed TRACE record, no CLI

## What

A Trust Record emitter: given a finished run's journal, produce a signed TRACE 0.2 Trust Record. No CLI surface in this slice — an internal API plus tests, so the CLI and CI slices have something real to wire.

Part of #4665, which holds the context and the upstream link.

Concretely:

- A module (suggested: `src/bernstein/core/observability/trust_record.py`) that maps one run journal onto the TRACE claim set: model identity per step, the policy/gate configuration hash, the tool-call tr

[Read the thread](https://github.com/sipyourdrink-ltd/bernstein/issues/4666) · 2026-08-27 · closed · 0 comments

### Default daemon install never ticks the schedule supervisor, despite docs claiming it is wired

## What happens

`bernstein daemon install` promises background operation, and the schedule subsystem's docs say the supervisor is "wired into the `bernstein daemon` hook" (`cli/commands/schedule_cmd.py:409-411`). Neither holds for a default install:

- `DEFAULT_COMMAND = "bernstein dashboard --headless"` (`cli/commands/daemon_cmd.py:35`).
- The dashboard never constructs a `ScheduleSupervisor` (grep across `cli/dashboard.py`: zero references).

So schedules only fire while an operator keeps `be

[Read the thread](https://github.com/sipyourdrink-ltd/bernstein/issues/4537) · 2026-08-25 · closed · 1 comment

### The finding artifact type is implemented but unreachable from both the MCP tool schema and the HTTP route

## What happens

The `finding` artifact type (SARIF-shaped findings) is implemented and tested but unreachable from both surfaces that post artifacts:

- Implementation: `core/evidence/run_artifacts.py:142-292,396-416` — validation, canonicalisation, recording.
- MCP: the tool schema enum stops at `["report", "table", "link"]` (`mcp/tool_schemas/bernstein_post_artifact.json:12`), so an agent calling `bernstein_post_artifact` cannot declare a finding.
- HTTP: `core/routes/task_artifacts.py` `_bui

[Read the thread](https://github.com/sipyourdrink-ltd/bernstein/issues/4533) · 2026-08-25 · closed · 0 comments

### Agency frontmatter 'tools: A, B' scalar explodes into characters and bypasses spawn-time capability enforcement

An agency agent whose frontmatter declares tools in the comma-separated scalar form

```yaml
tools: WebFetch, WebSearch, Read, Write, Edit

reaches agency_provider.py:367 as a single string, and

raw_tools: list[Any] = list(fm.get("tools") or [])
tools: list[str] = [str(t) for t in raw_tools]

iterates it character by character. The persisted spawn manifest shows the result:

"tools": ["adapter.Qwen CLI", "W", "e", "b", "F", "e", "t", "c", "h", ",", ...]

(observe

Read the thread · 2026-08-24 · closed · 1 comment

`bernstein pr` cannot be told which issue the run was for

bernstein pr cannot be told which issue a run was working on, so an issue-driven run opens a PR that neither reads like the issue nor closes it.

Two consequences:

The title comes from the goal. pr_cmd calls build_pr_title(summary.goal or summary.session_id, ...), and a goal composed from an issue carries the instructions handed to the run. A realistic goal produces:

fix: resolve GitHub issue #4345: Dead-agent orphan handling crashes t…

The resolve GitHub issue #N: preambl

Read the thread · 2026-08-22 · closed · 0 comments

Repo-root .mcp.json declares cwd ${PLUGIN_ROOT}: the Bernstein MCP bridge never starts for any client

Summary

The repo-root .mcp.json — the file every MCP-aware CLI reads to discover Bernstein's own bridge — declares a command that cannot start:

{
  "mcpServers": {
    "bernstein": {
      "command": "uv",
      "args": ["run", "bernstein", "mcp"],
      "cwd": "${PLUGIN_ROOT}"
    }
  }
}

${PLUGIN_ROOT} is a plugin-manifest placeholder. MCP clients do not expand it, so cwd resolves to a literal directory named ${PLUGIN_ROOT} that does not exist and the server never sta

Read the thread · 2026-08-22 · closed · 0 comments

Reject internal-host destinations in the MCP-catalog fetcher

Problem

src/bernstein/core/protocols/mcp_catalog/fetcher.py:87 validates each URL read out of a fetched MCP catalog with:

ensure_http_url(url, allow_http=True, source="mcp_catalog.fetcher")

ensure_http_url (src/bernstein/core/security/url_allowlist.py:36-91) checks scheme only, not the destination host. Unlike the skills-catalog fetcher, this call site already passes allow_http=True (plain HTTP is accepted, not just for loopback hosts), which makes host restriction mo

Read the thread · 2026-08-22 · closed · 0 comments

Add a strict host-restriction mode to ensure_http_url for third-party-derived URLs

Problem

ensure_http_url (src/bernstein/core/security/url_allowlist.py:36-91) validates only the URL scheme:

It checks scheme in {"http", "https"} (or https-only when allow_http=False).
Plain http:// is always accepted for hosts in _LOCAL_HOSTS (loopback) regardless of allow_http (lines 76-79).
Nothing after that resolves or inspects the destination host. There is no check anywhere in the file for private ranges, link-local addresses, or redirect targets (confirmed: no re

Read the thread · 2026-08-22 · closed · 0 comments

ensure_http_url does not restrict destination hosts for third-party-derived URLs

Problem

ensure_http_url (src/bernstein/core/security/url_allowlist.py) validates the URL scheme only. It does not restrict the destination host.

That is adequate for operator-configured URLs. But three call sites pass it URLs derived from third-party-authored content — entries inside a fetched index, not the operator-supplied index URL itself:

skills/catalog/fetcher.py
mcp_catalog/fetcher.py
the volunteer browse manifest fetch (added in #4273)

A crafted index entry can

Read the thread · 2026-08-22 · closed · 0 comments

verify receipt: integrity-only and provenance both exit 0

What happens

bernstein verify receipt has two verdict tiers: integrity-only (no --public-key; the embedded JWK self-attests) and provenance (pinned key). Both pass with exit 0. The tier is visible only in the human-readable verdict line.

A CI gate scripted as verify receipt $f && deploy with no --public-key configured therefore accepts a receipt that was rewritten, re-chained, and re-signed under an attacker's fresh embedded key — the integrity-only pass authenticates nothing ab

Read the thread · 2026-08-20 · closed · 0 comments

Codex adapter passes unsupported '--session-id' flag to 'codex exec', hard-breaking the integration (codex-cli 0.147.0)

What happened

role_model_policy:
  manager:
    cli: codex
    model: "gpt-5.5-mini"
    effort: low

$ bernstein
...
Spawn failure reason extracted for agent manager-... (adapter=Codex, exit_code=?):
codex: (no error pattern found, showing last 10 lines)
error: unexpected argument '--session-id' found
  tip: to pass '--session-id' as a value, use '-- --session-id'
Usage: codex exec [OPTIONS] [PROMPT]
       codex exec [OPTIONS] <COMMAND> [ARGS]
For more information, try '--h

[Read the thread](https://github.com/sipyourdrink-ltd/bernstein/issues/4135) · 2026-08-19 · closed · external user · 0 comments

### tests/unit/ has 12 files with @settings(...) and no shared profile plumbing, same missing-derandomize defect as #4024/#4044

Follow-up from #4044 (per review on PR #4108), which fixed the identical defect for `tests/contract/` (#4024) and `tests/property/` (#4044) via one shared profile registration each. `tests/unit/` has no equivalent shared conftest profile plumbing — each file calls `@settings(...)` directly — so this class of file needs its own, per-file fix rather than one central edit.

## What

Confirmed by direct grep against current `main` (`813bf6a` — note this supersedes the "18 files" figure #4044s own bo

[Read the thread](https://github.com/sipyourdrink-ltd/bernstein/issues/4116) · 2026-08-18 · closed · 1 comment

### volunteer: runner orchestration -- clone, sandboxed spawn, wall-clock, structured refusals

Part of the volunteer-workers umbrella (#3863). Split from #3869 ("task runner from claimed issue to receipt bundle") — see that issue for why. **Security-sensitive: a maintainer pairs on review**, same as the parent.

## Problem

Three primitives this program needs already exist and are independently tested, but nothing calls them together: `build_volunteer_profile` derives the sandbox containment from a manifest, `run_under_wall_clock` caps and kills a process tree, and `WorktreeManager.create

[Read the thread](https://github.com/sipyourdrink-ltd/bernstein/issues/4032) · 2026-08-16 · closed · 1 comment

The remaining reports are on [the project's issue tracker](https://github.com/sipyourdrink-ltd/bernstein/issues).

Reported issues for bernstein

Most discussed

Stream chain-anchored GenAI spans to OpenTelemetry pipelines over OTLP

Problem

Partner adapter wave: wrap agent SDKs and new CLI agents behind the conformance gate

Problem / Motivation

A2A server surface and agent-registry publication for a callable, discoverable node

Problem / Motivation

Add a typed activity boundary so any agent modality runs under the deterministic scheduler

Problem

Implement webhook signature verification for incoming requests

Description

Metadata

Implementation Suggestions

Task context pack: the container contract, deterministic and content-addressed, with no extractors

What

MCP bridge spec spawns bernstein.mcp.server, which has no main guard: bridge silently never starts

Summary

fix(mcp): serverInfo reports the MCP SDK version instead of the bernstein version

What happens

Why

bernstein pr cannot be told which issue the run was for

Repo-root .mcp.json declares cwd ${PLUGIN_ROOT}: the Bernstein MCP bridge never starts for any client

Summary

Reject internal-host destinations in the MCP-catalog fetcher

Problem

Add a strict host-restriction mode to ensure_http_url for third-party-derived URLs

Problem

ensure_http_url does not restrict destination hosts for third-party-derived URLs

Problem

verify receipt: integrity-only and provenance both exit 0

What happens

Codex adapter passes unsupported '--session-id' flag to 'codex exec', hard-breaking the integration (codex-cli 0.147.0)

What happened

`bernstein pr` cannot be told which issue the run was for