# Reported issues for contextweaver

Pod holds 22 of 249 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 [contextweaver](/mcp/contextweaver).

## Most discussed

### Deployment recovery: multiple versions absent from PyPI and MCP Registry

## Incident summary

The package publication pipeline has been failing since `v0.16.0`, leaving multiple published releases on GitHub that are not installable from PyPI or discoverable via the MCP Registry.

## Observed gaps (confirmed)

| Version | GitHub Release | PyPI | MCP Registry |
|---|---|---|---|
| `v0.15.0` | ✓ | ✓ | ✓ |
| `v0.16.0` | ✓ | ✓ | **✗** (MCP publish step failed) |
| `v0.17.0` | ✓ | **Likely missing** | **✗** |
| `v0.18.0` | ✓ | **✗** (blocked by missing benchmark snapshot) 

[Read the thread](https://github.com/dgenio/contextweaver/issues/849) · 2026-08-11 · closed · 8 comments

### [summarize] Optional LLM-backed summarizer/extractor plugin

## Context

The Context Firewall (`src/contextweaver/context/firewall.py`) intercepts large tool outputs and produces compact `ResultEnvelope` summaries. However, the summarization and extraction logic is **hardcoded** rather than using the swappable protocols already defined in the codebase.

### Current state

**Protocols exist but aren't wired:**
- `Summarizer` protocol (`src/contextweaver/protocols.py` ~L256–265): defines `summarize(raw, metadata) -> str`
- `Extractor` protocol (`src/context

[Read the thread](https://github.com/dgenio/contextweaver/issues/26) · 2026-03-02 · closed · 5 comments

### Add a `contextweaver handoff` CLI subcommand for session-continuity packs

## Summary

Expose the existing session-handoff pack builder (`context/handoff.py`, issue #294) on the CLI: `contextweaver handoff --session session.json --out handoff.md|json` to generate a budgeted continuity snapshot, and an ingest path to seed a new session from a pack.

## Why this matters

Session handoff is one of the library's most operator-relevant features (resuming long agent sessions, shift handovers between agents or humans), but it is reachable only through Python. The CLI already 

[Read the thread](https://github.com/dgenio/contextweaver/issues/629) · 2026-06-13 · closed · 4 comments

### Extend the MCP gateway to budget and route MCP resources and prompts, not just tools

## Summary

Extend the gateway/proxy runtime beyond tools to the other two first-class MCP context types: resources and prompts. Apply the same bounded-choice and firewall treatment — browse a bounded shortlist of resources/prompts instead of full listings, and pass large resource reads through the artifact-backed firewall.

Priority: P1 · Confidence: High · Strategic ("big swing") proposal

## Why this matters

MCP defines three context primitives — tools, resources, prompts — and contextweaver

[Read the thread](https://github.com/dgenio/contextweaver/issues/555) · 2026-06-10 · closed · 4 comments

### [Blocked until D1 evidence] D2/D3 comparative falsification vs native tool search

## Summary

Build the decisive competitive evaluation for ContextWeaver's product thesis.

The old framing — "naive all tools/full history" versus ContextWeaver — is retained only as a historical sanity baseline. It is not sufficient evidence for adoption because modern providers and runtimes increasingly offer native tool search/deferred loading and programmatic tool-use mechanisms.

The benchmark must answer:

> **Does ContextWeaver add meaningful value beyond strong contemporary alternatives,

[Read the thread](https://github.com/dgenio/contextweaver/issues/445) · 2026-06-10 · open · 4 comments

### [Feature] HTTP sidecar mode: language-agnostic route/compact API for non-Python agents

## Summary

contextweaver's engines are Python-only, but much of the agent ecosystem
(MCP clients, Vercel AI SDK apps, Go/TS services) is not. This issue adds a
sidecar mode — `contextweaver serve-api` — exposing the two highest-value
primitives over a small, versioned HTTP/JSON API: tool routing
(`/v1/route`) and tool-result compaction (`/v1/compact`), so any language
can use contextweaver without embedding Python.

## Why this matters

- The "too many tools / huge tool results" problem is lang

[Read the thread](https://github.com/dgenio/contextweaver/issues/427) · 2026-06-09 · closed · 3 comments

### Add runtime authorization and policy gate before `tool_execute`

## Problem

The MCP gateway currently makes tool execution efficient, but it does not yet provide a runtime authorization/policy layer before dispatching selected tools.

This is critical for the target use case: VS Code/Copilot, Claude, or other coding agents connected to several MCP servers with hundreds of tools. In that environment, reducing the visible tool surface to `tool_browse`, `tool_execute`, and `tool_view` saves prompt tokens, but it also concentrates access to powerful tools behind

[Read the thread](https://github.com/dgenio/contextweaver/issues/373) · 2026-06-06 · closed · 3 comments

### [D1 survival experiment] Ship the minimal capability snapshot + semantic diff path

## Decision

This is the **primary implementation gate** for the ContextWeaver survival/distribution experiment in #855.

For D1, the product proposition is deliberately smaller than the current compiler/runtime architecture:

> **Capture an agent's effective capability surface, commit it, and see semantically meaningful changes before deployment.**

The purpose of this issue is to make that proposition small enough to distribute and falsify. It is **not** a new roadmap epic.

## User workflow

[Read the thread](https://github.com/dgenio/contextweaver/issues/856) · 2026-08-19 · closed · 2 comments

## Most recent

### [Product validation] Distribution gate: distinguish no demand from no reach

## Decision this issue exists to protect

ContextWeaver currently has weak evidence of independent retained use. That is important, but **absence of adoption is not by itself evidence that the product problem is weak if distribution has never been competently tested**.

This issue adds a distribution-quality gate to #758/#840 so the survival review can distinguish:

1. **no reach** — qualified users did not meaningfully encounter/evaluate the product;
2. **positioning/onboarding failure** — they

[Read the thread](https://github.com/dgenio/contextweaver/issues/855) · 2026-08-19 · open · 2 comments

### Publish current weaver-spec conformance bundle at .well-known/conformance.json

## Context

The weaver-spec public scoreboard registers ContextWeaver at:

`https://contextweaver.dev/.well-known/conformance.json`

but the endpoint currently publishes no bundle, so ContextWeaver appears as `not-submitted` despite existing weaver-spec adapter/conformance work.

Coordination:
- dgenio/weaver-spec#170 — ecosystem scoreboard rollout
- dgenio/weaver-spec#169 — current compatibility declarations
- this repo #469 — pin gating conformance to an immutable spec version

## Goal

Publis

[Read the thread](https://github.com/dgenio/contextweaver/issues/846) · 2026-08-11 · open · 0 comments

### [P0 release] Restore PyPI publishing: v0.18.0 is blocked by missing benchmark snapshot

## Incident

The public release/install surfaces are inconsistent:

- GitHub latest release is **v0.18.0**, published 2026-08-09.
- PyPI still serves **0.16.0**, uploaded 2026-06-23.
- The v0.18.0 `Publish to PyPI and MCP Registry` workflow completed with **failure** before the publish job ran.
- The failed step is `Verify release benchmark snapshot`.
- At tag `v0.18.0`, `benchmarks/results/history/` contains `0.16.0.json` and `0.17.0.json` but **no `0.18.0.json`**.

The release workflow explici

[Read the thread](https://github.com/dgenio/contextweaver/issues/837) · 2026-08-10 · closed · 1 comment

### Pin and verify mcp-publisher before executing it in the OIDC release job

## Problem

The PyPI portion of `.github/workflows/publish.yml` is deliberately hardened: third-party Actions are pinned to immutable SHAs, PyPI uses Trusted Publishing/OIDC, and build provenance is attested.

The subsequent MCP Registry job breaks that same trust model:

```sh
curl -L "https://github.com/modelcontextprotocol/registry/releases/latest/download/mcp-publisher_...tar.gz" | tar xz mcp-publisher
chmod +x mcp-publisher
./mcp-publisher login github-oidc
./mcp-publisher publish
```

The 

[Read the thread](https://github.com/dgenio/contextweaver/issues/836) · 2026-08-10 · closed · 2 comments

### [Maintenance, not D1] Migrate shipped MCP integration to Python SDK v2

## Why

The MCP Python SDK v2 line is now stable, while contextweaver intentionally declares `mcp>=1.19.0,<2` because the current adapters import v1 APIs that changed or disappeared in v2. Dependabot PR #826 attempted to widen the ceiling automatically; that is dependency automation doing architectural migration work.

Keep `<2` until this issue is implemented. Dependabot is configured to ignore the MCP major version so the migration is deliberate rather than a recurring bot PR.

## Known migrat

[Read the thread](https://github.com/dgenio/contextweaver/issues/827) · 2026-08-10 · open · 1 comment

### feat(deps): update MCP adapter layer for SDK 2.x compatibility

## Summary

PR #817 pinned `mcp<2` as a workaround to unblock CI after the `mcp==2.0.0` release introduced breaking API changes. This issue tracks the actual migration work: updating all affected adapter imports and call sites to the MCP 2.x surface so the ceiling can be lifted.

## Background

MCP 2.0.0 is a breaking release. The specific failures surfaced in PR #799's CI run (commit `1b66822`) and documented in PR #817:

### mypy failures (26 errors across 8 files)
- `Server` generic arity cha

[Read the thread](https://github.com/dgenio/contextweaver/issues/825) · 2026-08-10 · closed · 1 comment

### feat: Compile resource closure and add a host-provided ResourceResolver

## Parent

Part of #758. Consumed by the bundle implementation in #794 and runtime hydration in #408.

## Summary

Make resources first-class compiled inputs so advertised hydration is reproducible, bounded and safe.

ContextWeaver compiles resource descriptors and validates supplied content. It performs no network access by default. A host-provided `ResourceResolver` owns authentication, network/filesystem access, retries, timeouts, operational cache and audit.

## `ResourceDescriptor`

A versi

[Read the thread](https://github.com/dgenio/contextweaver/issues/795) · 2026-07-12 · closed · 1 comment

### feat: Define CapabilitySourceAdapter snapshots and multi-source discovery

## Parent

Part of #758. Governed by the adapter policy in #651 and surfaced by the analysis command in #409.

## Summary

Introduce the framework-independent source boundary used by the offline compiler and migrate every currently supported source/protocol adapter to it.

```python
class CapabilitySourceAdapter(Protocol):
    adapter_id: str
    adapter_version: str

    def discover(
        self,
        source: object,
        *,
        configuration: object,
    ) -> CapabilitySourceSnapsh

[Read the thread](https://github.com/dgenio/contextweaver/issues/793) · 2026-07-12 · closed · 1 comment

### Add verified resource resolver before exposing external resources to agents

## Context

Context construction should not just retrieve useful information; it should also control which resources are allowed to enter the agent's working context. A model may hallucinate a plausible repo, package, tool, skill, or MCP server. If contextweaver blindly enriches that reference, the downstream agent may treat the wrong resource as legitimate.

## Goal

Add a verified resource-resolution layer that converts ambiguous resource references into provenance-backed context cards.

## Pr

[Read the thread](https://github.com/dgenio/contextweaver/issues/786) · 2026-07-09 · open · 0 comments

### Load Expertise Packs as bounded context sources

## Context
Related spec anchor: https://github.com/dgenio/weaver-spec/issues/184
Related LessonWeaver producer issue: https://github.com/dgenio/lessonweaver/issues/366

Agentic coding is most effective when the agent receives explicit, bounded expertise: goals, constraints, assumptions, verification signals, and known failure modes. ContextWeaver should be able to consume that expertise as structured context rather than free-form prompt text.

## Problem
Without a structured `ExpertisePack`, con

[Read the thread](https://github.com/dgenio/contextweaver/issues/776) · 2026-07-06 · closed · 1 comment

### [Parked pending adopter demand] UnderstandingFrame coding-agent context artifact

## Context

Generated code is only the projection; the durable asset is the validated understanding around assumptions, boundaries, prior failures, and evidence.

ContextWeaver is a good place to make that idea operational: when a coding agent receives context, it should not only receive files. It should also receive relevant lessons, known assumptions, contracts, and risks.

## Goal

Extend context assembly so coding agents can receive an explicit "understanding frame" alongside source snippets

[Read the thread](https://github.com/dgenio/contextweaver/issues/770) · 2026-07-05 · open · 0 comments

### Support LessonWeaver lesson bundles as lifecycle-aware context sources

## Context

`lessonweaver` can produce durable learning from traces: reviewed lessons, known traps, eval cases, tool policies, prompt constraints, routing rules, and project conventions.

If those lessons are exported as OKF / LLM Wiki-style Markdown nodes, `contextweaver` should be able to consume them as a distinct context source without treating every lesson as equally authoritative or always prompt-worthy.

Related work:

- #736 — Add OKF bundle loader as a context source
- #763 — Ingest gen

[Read the thread](https://github.com/dgenio/contextweaver/issues/767) · 2026-07-05 · closed · 1 comment

### Gate server.json and CITATION.cff in version-drift checks; fix stale versions (0.15.0 / 0.10.0)

## Problem

The two version-bearing files with **no** CI gate are exactly the two that have drifted:

- `server.json` (MCP Registry manifest) declares `"version": "0.15.0"` (top level and `packages[0].version`) while `pyproject.toml` is `0.16.0` — so the v0.16.0 release either re-published 0.15.0 metadata to the registry or the `publish-mcp-registry` job failed after its 6×30s retry loop.
- `CITATION.cff` says `version: 0.10.0`, `date-released: 2026-05-22` — six releases stale, despite its own c

[Read the thread](https://github.com/dgenio/contextweaver/issues/747) · 2026-07-04 · closed · 0 comments

### Align tool_view artifact egress with the drilldown sensitivity policy gate (or document raw egress explicitly)

## Problem

The two artifact-drilldown surfaces enforce different policies. `ContextManager.drilldown` enforces the `sensitivity_floor` / `allow_redacted_drilldown` gate (issue #451). `ProxyRuntime.view` (`tool_view`) does not: `execute()` stores the full raw upstream text/binaries to the artifact store, and `view()` calls `store.drilldown(handle, selector)` with no sensitivity check. With `redact_secrets=True`, ChoiceCards and firewall summaries are scrubbed — but the raw tool output (embedded 

[Read the thread](https://github.com/dgenio/contextweaver/issues/746) · 2026-07-04 · closed · 0 comments

The remaining reports are on [the project's issue tracker](https://github.com/dgenio/contextweaver/issues).