Reported issues for ChainWeaver

Pod holds 23 of 109 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 ChainWeaver.

Most discussed

🌟ChainWeaver x WisePick - Turning Hardcoded Tool Flows into Self-Optimizing Infrastructure

👋😊 Hi @dgenio,

Stumbled upon ChainWeaver while tracking deterministic execution patterns in LangGraph, and I have to say—the "LLM-free compiled flow" approach is brilliant. Treating predictable multi-tool chains like a compiled pipeline rather than an ad-hoc runtime guess solves a massive latency and token bleeding problem. 🍧✨

However, as flows grow, developers will inevitably hit the "hardcoding wall"—manually wiring input_mapping and predicting execution capabilities beforehand becomes britt

Read the thread · 2026-05-25 · closed · external user · 16 comments

Investigation: redaction policy for ingested coding-agent traces

Summary

Investigate adding a redaction hook at the trace-ingestion boundary (load_agent_trace) so tool-call arguments and outputs in imported coding-agent traces can be sanitized before mining, scoring, reporting, fixture sharing, and persistence/export boundaries.

Why this matters

The traces pipeline ingests JSONL logs of real agent sessions — file contents, shell arguments, API parameters — which routinely contain credentials, tokens, and private paths. Everything downstream of inge

Read the thread · 2026-06-10 · closed · 4 comments

distribution: ship a first-class MCP server and submit to the MCP registry + awesome-mcp-servers

Why

ChainWeaver is MCP-native (chainweaver[mcp]), and the MCP ecosystem is the single best-trafficked discovery channel for this exact audience. Being listed in the official MCP registry and the popular awesome-mcp-servers lists is high-leverage passive reach — qualified users find you without a launch push.

Proposal

• Polish chainweaver.mcp into a documented, first-class "expose your flows as MCP tools" server with a one-command start and a minimal config example.
• Write a ded

Read the thread · 2026-05-30 · closed · 4 comments

Add chainweaver fuzz command for property-based flow testing

Context

A property-based fuzzing harness is most useful if it can run from the CLI and CI.

ChainWeaver already exposes commands such as run, validate, check, profile, diff, attest, suggest, and doctor. A fuzz command would make failure discovery part of the same workflow.

Proposal

Add a chainweaver fuzz CLI command that runs property-based tests against a flow file.

Illustrative shape:

chainweaver fuzz flows/my_flow.flow.yaml \
  --tools my_pkg.tools \
  -

[Read the thread](https://github.com/dgenio/ChainWeaver/issues/481) · 2026-06-29 · closed · 2 comments

### First-class OpenAI Agents SDK integration (#315)

# First-class OpenAI Agents SDK integration

**Parent:** #315 (Production adoption gaps)
**Priority:** P3 — reduces boilerplate, improves DX

## Problem

ChainWeaver has export helpers (`flow_to_callable`, `flow_to_openai_function`) and a cookbook example, but **no first-class integration module**. Users must manually wire schemas, callbacks, and error handling every time.

## Current Boilerplate (from cookbook)

```python
from agents import Agent, FunctionTool
from chainweaver.expo

[Read the thread](https://github.com/dgenio/ChainWeaver/issues/321) · 2026-06-08 · closed · 2 comments

### Redis cache backend for StepCache (#315)

# Redis cache backend for StepCache

**Parent:** #315 (Production adoption gaps)
**Priority:** P2 — required for multi-instance deployments (Cloud Run, K8s)

## Problem

ChainWeaver provides two cache implementations:
- `InMemoryStepCache` — dict-backed, process-local, lost on restart
- `FileStepCache` — JSON-on-disk, not suitable for ephemeral containers

In Cloud Run, Cloud Functions, or Kubernetes, containers are **ephemeral**. In-memory cache is useless for anything beyond a singl

[Read the thread](https://github.com/dgenio/ChainWeaver/issues/319) · 2026-06-08 · closed · 2 comments

### A2A (Agent-to-Agent) protocol integration (#315)

# A2A (Agent-to-Agent) protocol integration

**Parent:** #315 (Production adoption gaps)
**Priority:** P2 — needed for deterministic multi-agent orchestration

## Problem

ChainWeaver has MCP integration (`MCPToolAdapter`, `FlowServer`), but **zero support for Google's A2A (Agent-to-Agent) protocol**. Modern agent platforms increasingly use A2A for cross-team, cross-service agent delegation.

## Concrete Use Case

A customer support orchestrator has a fixed pattern:
1. Classify user 

[Read the thread](https://github.com/dgenio/ChainWeaver/issues/318) · 2026-06-08 · closed · 2 comments

### Dynamic parameter injection: hide params from LLM schema, inject at runtime (#315)

# Dynamic parameter injection: hide params from LLM schema, inject at runtime

**Parent:** #315 (Production adoption gaps)
**Priority:** P1 — blocks all authenticated tool flows

## Problem

ChainWeaver's `FlowStep.input_mapping` only supports:
- `str` values → key lookup in execution context
- Literal constants (`int`, `float`, `bool`) set at flow-definition time

There is **no mechanism** to inject a parameter at `execute_flow_async()` time while **hiding it from the LLM-visible inp

[Read the thread](https://github.com/dgenio/ChainWeaver/issues/316) · 2026-06-08 · closed · 2 comments

## Most recent

### External review wanted: threat-model macro-capability authorization before v1

## Why this exists

ChainWeaver's v1 bar now requires at least one **independent security/threat-model review** by someone other than the principal maintainer.

The highest-risk boundary is not generic Python execution. It is what happens when a repeated multi-tool path is promoted into one named deterministic capability: the convenience of a macro must not silently aggregate privileges or erase child approval boundaries.

The detailed invariant is tracked in #554.

## Review question

Assume an

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

### Introduce explicit privacy profiles for traces, caches, checkpoints, and analysis artifacts

## Problem

ChainWeaver applies redaction primarily to logs/display, while multiple retained data surfaces may still store raw values: execution results, observation traces, cache entries, checkpoints, events and generated analysis artifacts.

The new platform workflow will ingest tool-call telemetry from coding agents and MCP systems, making data minimization and content availability part of the product contract rather than a display concern.

## Goal

Introduce explicit, consistently enforced 

[Read the thread](https://github.com/dgenio/ChainWeaver/issues/527) · 2026-07-12 · open · 0 comments

### Add privacy-safe OpenTelemetry GenAI/MCP batch ingestion

## Problem

ChainWeaver's observation inputs are currently fragmented across native execution traces, agent JSONL formats and vendor-specific integrations. Platform teams increasingly already export agent/model/tool telemetry through OpenTelemetry, but ChainWeaver has no canonical inbound batch path for OTel GenAI/MCP data.

Building an OTLP receiver or observability backend would duplicate the OpenTelemetry Collector and expand ChainWeaver into infrastructure it should not own.

## Product deci

[Read the thread](https://github.com/dgenio/ChainWeaver/issues/523) · 2026-07-12 · open · 0 comments

### Fix synchronous Tool timeout semantics so calls return near the deadline

## Problem

The synchronous tool-call path uses `future.result(timeout=...)` inside a `ThreadPoolExecutor` context manager. When the timeout is raised, leaving the context waits for the worker to finish, so control is not returned near the declared timeout.

A caller may receive a timeout exception only after the underlying function has already run for its full duration. This makes the timeout contract misleading and can block flow execution far beyond policy limits.

## Goal

Provide honest, te

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

### Add deterministic safe-fetch flow before executing external agent resources

## Context

Agent workflows often compress several risky steps into one fuzzy action: "find repo/tool, fetch it, read instructions, install dependencies, run it". For safe agent execution, those steps should be explicit and deterministic.

## Goal

Add a reusable safe-fetch chain for external resources:

`resolve → verify → fetch → inspect → policy-check → approve/sandbox/deny → execute`

## Proposed flow

1. **Resolve** the requested resource into a canonical resource identity.
2. **Verify** ow

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

### Add adaptive execute-observe-replan loop for ChainWeaver flows

## Context

Make chain execution more robust by using a closed loop: plan, execute a small step, observe the result, compare it with expectations, update local workflow state, and replan when needed.

This is useful when files are renamed, tool responses differ from the initial assumption, APIs differ from docs, or a previous step returns partial evidence.

## Proposal

Add an optional adaptive execution mode where each step may declare expected observations before execution. After the step runs

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

### Future: consolidated governed data-science validation example

## Status and priority

This is a valid future vertical example, but it is outside the current governed-macro-tool beachhead milestone. Do not implement it before the OTel trace → AnalysisBundle → approved artifact → deployment → MCP golden path is complete with independent evidence.

This issue consolidates the overlapping scopes previously described in #500 and #515.

## Future goal

Provide one coherent, offline example showing how predictable data-science validation stages can be expressed a

[Read the thread](https://github.com/dgenio/ChainWeaver/issues/508) · 2026-07-06 · open · 0 comments

### Bind OKF/LLM Wiki context nodes to compiled workflow steps

## Context

LLM Wiki / OKF-style knowledge graphs are useful when context is not treated as a blob, but as a set of typed, referenceable knowledge nodes.

For `ChainWeaver`, the interesting use case is not building another wiki. It is making workflow context requirements explicit: a deterministic step should be able to declare which repository knowledge, policy notes, architecture decisions, lessons, or instructions it needs, and the compiler/runtime should make those requirements inspectable.

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

### Test positioning hypothesis: trace evidence → governed deterministic capabilities

## Status: positioning hypothesis, not settled category

The red-team review found that **"deterministic workflow runtime" is not a defensible category by itself**. Plain Python, LangGraph and provider SDKs can already execute known paths deterministically.

This issue therefore treats the positioning as a hypothesis to validate through #553 before broad external promotion.

The differentiated product candidate is:

> **ChainWeaver analyzes how agents actually use tools, finds repeated model-med

[Read the thread](https://github.com/dgenio/ChainWeaver/issues/497) · 2026-07-04 · open · 0 comments

### `chainweaver validate`/`check` resolve untrusted schema refs with no allowlist option

## Problem

`input_schema_ref` / `output_schema_ref` / `context_schema_ref` on a `Flow` are `"module:qualname"` strings resolved via `importlib.import_module` at load time. The `SchemaRefAllowlist` guard that can restrict this exists but defaults to permissive, and only the `run`/`serve` CLI commands expose `--schema-ref-allow` to opt in. `validate` and `check` — the commands most likely to be pointed at an untrusted contributor's flow file, and the entry point the shipped `.github/actions/chain

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

### FlowServer network transports default to no auth, no rate-limit, and full error detail

## Problem

A default-constructed `FlowServer` served over a network transport (`sse`, `streamable-http`) has no authenticator, no authorizer, and no rate limiter configured, and `error_detail` resolves to `"full"` — raw internal exception text (`"{type}: {message}"`) is returned to any connected MCP client on failure. `readiness_report()`, which would flag this, only runs when a `MCPServerProfile` is explicitly supplied.

## Evidence

- All trust hooks default to `None`: `chainweaver/mcp/server

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

### Validate fallback output-schema compatibility (#338 follow-up)

## Summary

Follow-up to #338 (PR #455). #455 validates a fallback tool's **input** schema at compile time and runtime, but explicitly leaves **output-schema** compatibility out of scope. A fallback whose `output_schema` differs from the primary's can pass input validation, run successfully, and then merge an unexpected output shape into the accumulated context — breaking downstream steps or the flow `output_schema` in a way no current check catches.

## Why this matters

The fallback path is th

[Read the thread](https://github.com/dgenio/ChainWeaver/issues/457) · 2026-06-15 · closed · 0 comments

### Add MCP Production Profile Packs With Secure Defaults

## Description
Teams need a repeatable baseline for running MCP exposure in production.

## Use case
Operators want clear profiles instead of assembling many knobs by hand.

## Proposed solution
- Add profile packs: strict, balanced, and trusted-network.
- Each profile sets timeout, approval, logging, retry, and side-effect defaults.
- Provide profile diff output for audit reviews.
- Include threat notes and deployment examples.
- Add validation command for profile readiness checks.

## Alternat

[Read the thread](https://github.com/dgenio/ChainWeaver/issues/446) · 2026-06-14 · closed · 1 comment

### Add `chainweaver init` Scaffolder for First Flow Project

## Description
New users must create files manually before seeing value.

## Use case
A first-time user should generate a runnable flow project in one command.

## Proposed solution
- Add `chainweaver init` to scaffold tool, flow file, and run script.
- Offer templates: linear flow, DAG flow, and MCP-ready starter.
- Include a `--with-tests` option that adds one passing test.
- Print exact next commands after generation.
- Add docs and example output snapshots.

## Alternatives considered
- Publ

[Read the thread](https://github.com/dgenio/ChainWeaver/issues/441) · 2026-06-14 · closed · 0 comments

### Add FlowServer Authorization Callback Hooks

## Description
FlowServer lacks a first-class authorization decision point per call.

## Use case
Operators need deny/allow decisions before flow execution starts.

## Proposed solution
- Add optional authorization callback in FlowServer request path.
- Callback receives flow name, input summary, caller metadata, and trace id.
- Denied requests return typed error with safe reason code.
- Emit audit event for allow and deny decisions.
- Document default-deny and allowlist examples.

## Alternativ

[Read the thread](https://github.com/dgenio/ChainWeaver/issues/443) · 2026-06-14 · closed · 1 comment

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