# 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](/mcp/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](https://github.com/sipyourdrink-ltd/bernstein/issues/2526) · 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:

1. **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](https://github.com/sipyourdrink-ltd/bernstein/issues/2610) · 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](https://github.com/sipyourdrink-ltd/bernstein/issues/2609) · 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](https://github.com/sipyourdrink-ltd/bernstein/issues/2311) · 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](https://github.com/sipyourdrink-ltd/bernstein/issues/482) · 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](https://github.com/sipyourdrink-ltd/bernstein/issues/4646) · 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](https://github.com/sipyourdrink-ltd/bernstein/issues/4313) · 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:

```python
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

```python
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:

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

(observe

[Read the thread](https://github.com/sipyourdrink-ltd/bernstein/issues/4444) · 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](https://github.com/sipyourdrink-ltd/bernstein/issues/4353) · 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:

```json
{
  "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](https://github.com/sipyourdrink-ltd/bernstein/issues/4315) · 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:

```python
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](https://github.com/sipyourdrink-ltd/bernstein/issues/4302) · 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](https://github.com/sipyourdrink-ltd/bernstein/issues/4300) · 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](https://github.com/sipyourdrink-ltd/bernstein/issues/4286) · 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](https://github.com/sipyourdrink-ltd/bernstein/issues/4208) · 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

```yaml
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).