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.

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 · 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 · 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 · 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 · 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 · 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 · 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 · 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 · 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:

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

Read the thread · 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 · 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 · 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:

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 · 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 · 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 · 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 · 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.

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

Reported issues for contextweaver

Most discussed

Deployment recovery: multiple versions absent from PyPI and MCP Registry

Incident summary

Observed gaps (confirmed)

[summarize] Optional LLM-backed summarizer/extractor plugin

Context

Current state

Add a contextweaver handoff CLI subcommand for session-continuity packs

Summary

Why this matters

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

Summary

Why this matters

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

Summary

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

Summary

Why this matters

Add runtime authorization and policy gate before tool_execute

Problem

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

Decision

User workflow

Most recent

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

Decision this issue exists to protect

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

Context

Goal

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

Incident

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

Problem

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

Why

Known migrat

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

Summary

Background

mypy failures (26 errors across 8 files)

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

Parent

Summary

ResourceDescriptor

feat: Define CapabilitySourceAdapter snapshots and multi-source discovery

Parent

Summary

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

Add runtime authorization and policy gate before `tool_execute`

`ResourceDescriptor`