pod
Other formats agents might prefer:
markdownjsonllms.txt

Agent? You probably want markdown or json, or Pod over MCP.

Reported issues for AVCS

Pod holds 14 of 14 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 AVCS.

Most discussed

operation.propose MCP tool only authors whole-file put_file; no way to submit a base-relative edit_file (no 3-way-mergeable edits via MCP)

Summary

The MCP avcs.operation.propose tool accepts only a whole-file content string and is hardwired to repo.proposeFileWrite(...), which emits a put_file operation. The core supports a second, base-aware edit kind — edit_file (repo.proposeEdit, op body carries baseBlobOid) — that enables line-level 3-way merge of concurrent edits to the same file. That kind is not exposed by any MCP tool. operation.backport only re-ports an existing op, so operation.propose is the only

Read the thread · 2026-06-17 · closed · 1 comment

avcs.decision.record human-actor gate is a soft string check — an agent can forge a human decision (no signature enforcement)

Summary

The MCP tool avcs.decision.record gates only on a string check — actor.kind === "human" (in src/mcp/server.ts, it throws "requires a human actor; agents may not resolve their own conflicts"). It does not require or verify a signature. So any caller that passes actor.kind: "human" is accepted — an agent can forge a human decision (conflict resolution, public-API-break sign-off, etc.) under a human's name. The audit-ledger invariant *"an agent may not decide its own co

Read the thread · 2026-06-17 · closed · 1 comment

Gated (pending-evidence) ops are silently omitted from materialize; computed merge is unretrievable before acceptance

Summary

materialize / view_materialize silently omit operations that are pending the evidence gate (effects.changesBehavior: true with no passing-test evidence). As a result, avcs's computed 3-way merge of those ops (e.g. concurrent edits to a shared wiring file) is not visible anywhere, and there is no way to obtain it before accepting the ops. But you can't justify accepting them without first inspecting/testing the merged result — a chicken-and-egg deadlock.

Found while dogfoo

Read the thread · 2026-06-17 · closed · 1 comment

MCP has no tool to read object/blob content (no equivalent of CLI show)

Summary

The avcs MCP surface has no tool to read an object's content (a blob, or a put_file op's file body). An agent working purely through MCP cannot retrieve the file content authored by another agent's operation — especially a pending/gated one that hasn't materialized yet. The CLI has avcs show <oid>, but there is no MCP equivalent.

Found while dogfooding avcs to coordinate parallel AI-agent development (Phase D of a separate project): a coordinator needed the merged/authored co

Read the thread · 2026-06-17 · closed · 1 comment

No CLI command records a conflict decision — avcs conflicts names a debt the CLI cannot pay

Symptom

avcs conflicts lists the decisions a human owes, but there is no CLI command that records one. The MCP surface has avcs.decision.record; the human-facing CLI has no equivalent, so a human working without an agent has to drop into the library API to get past an L2 conflict.

Repro (avcs 0.41.1)

Two clones edit the same line; the second land is refused with a conflict packet:

avcs conflicts                 # shows the conflict object, both operations, needs_human
avc

[Read the thread](https://github.com/izagood/avcs/issues/129) · 2026-08-31 · closed · 0 comments

### `avcs undo` leaves the working tree unchanged with no hint that `avcs checkout` finishes the job; `log` shows undone ops unmarked

## Symptom

`avcs undo --last` removes the op from the view, but (a) the working-tree file still contains the undone change, with no message saying `avcs checkout` re-projects it, and (b) `avcs log` afterwards still lists the undone op with no marker, so history reads as if the undo never happened.

## Repro (avcs 0.40.0, macOS, Node 22)

```bash
mkdir demo && cd demo
printf 'a\n' > f.txt
npx -y @izagood/avcs@0.40.0 init .
npx -y @izagood/avcs@0.40.0 import . -m 'initial import'
printf 'a\nb\n' 

[Read the thread](https://github.com/izagood/avcs/issues/118) · 2026-08-31 · closed · 0 comments

### git branch maps to a line (divergence) instead of a workspace (convergence), so land/integration never runs

`lineFor()` (`src/cli.ts`) maps any non-`main`/`master` git branch to an avcs **line**. But `docs/16-workspace-scope.md` §4.1 draws the opposite distinction:

| | line | workspace |
|---|---|---|
| purpose | **divergence** (keep `v1.x` forked permanently) | **convergence** (work → verify → land onto base) |
| lifetime | long-lived | short-lived |

A topic branch is convergent work, so it should map to a **workspace**; mapping it to a line puts it in the permanently-divergent scope. Because `mate

[Read the thread](https://github.com/izagood/avcs/issues/75) · 2026-08-27 · closed · 0 comments

### git-bridge capture emits put_file, so concurrent edits to one file can never 3-way merge

`Repo.commitWorkingTree` (`src/api/repo.ts`) captures every changed file via `proposeFileWrite`, which emits `body.kind = "put_file"` — a whole-file write with no merge base.

Per `docs/15-language-neutral-core.md` §3, two concurrent `put_file` ops share no base and therefore **cannot** be 3-way merged: they land as an L2 conflict requiring a policy or human decision. Only `edit_file` (which carries `baseBlobOid`) reaches the `merge3` substrate where disjoint hunks auto-merge as L1.

**Consequen

[Read the thread](https://github.com/izagood/avcs/issues/72) · 2026-08-27 · closed · 0 comments

## Most recent

### gitCliSource: no -- separator (argument injection), no timeout, and inherited git config (redirects followed)

**Context.** `gitCliSource` (added in #67) shells out to `git clone --bare --quiet <source> <dest>` and `git rev-list … <ref>`. Three hardening gaps surfaced while reviewing an embedder's SSRF policy work on top of it. All three are in the importer, not in the caller.

**1. No `--` separator → argument injection.**
`source` and `ref` reach git as positional arguments with no `--` terminator, so a value beginning with `-` is parsed as an option. An embedder that (deliberately) allows local paths 

[Read the thread](https://github.com/izagood/avcs/issues/71) · 2026-08-27 · closed · 0 comments

### Hook timeout does not cover the store-lock wait — git commit blocks indefinitely while another avcs process holds the store

**Context.** Follow-up to #33 (git-bridge hooks hang; a hook timeout was added). The timeout does not appear to cover the store-lock wait: with another long-lived avcs process holding the repo store (an `avcs mcp` server on the same repo), commit-time ingest behaves inconsistently.

**Repro.**
1. A repo with `avcs install-hooks` (sidecar mode), containing a moderately large tree (~300 files already imported).
2. One or more long-lived `avcs mcp` processes serving the same repo (as an agent-facin

[Read the thread](https://github.com/izagood/avcs/issues/64) · 2026-08-27 · closed · external user · 0 comments

### A branch name containing '/' breaks the git hook: setRef treats the ref name as a path

A git branch whose name contains `/` — `feature/x`, `fix/y`, the convention most teams use — breaks the AVCS git hook. `git commit` fails and the commit does not happen.

Found while dogfooding: committing on a branch called `fix/recovery-nonexistent-cli`.

**Environment:** avcs 0.22.0, Linux.

## Reproduce

```bash
mkdir repro && cd repro && git init -q .
avcs init
printf 'x\n' > a.txt

git checkout -qb simple
git add -A && git commit -m ok          # succeeds

git checkout -qb feature/x
printf

[Read the thread](https://github.com/izagood/avcs/issues/52) · 2026-07-25 · closed · 0 comments

### No CLI or MCP surface provisions a local signing key, so signed actions are unreachable from a fresh repo

`Repo.provisionOwnerKey` is the only way to mint a local signing key, and it is reachable from neither the CLI nor MCP — it appears in `src/` exactly once outside its own definition, in an error message, and is otherwise called only from a test.

The practical effect: any action that must be signed (recording a decision, pushing to an auth-required hub) fails for a fresh repo, and there is no documented way forward. Found while setting a repo up against a hub that requires signed writes.

**Envi

[Read the thread](https://github.com/izagood/avcs/issues/51) · 2026-07-25 · closed · 0 comments

### hubClient sends no credential on reads, so a read-gated hub cannot serve a client at all (push included)

`hubClient` sends no credential on any read, so a hub that gates reads cannot serve an avcs client at all — including for **push**, which begins with `GET /have`.

Found by pointing a stock client at a hub that authenticates reads: `avcs push` fails with `GET /have failed: 401 Unauthorized` before a single object moves.

**Environment:** avcs 0.22.0.

## The four bare reads

```ts
// src/hub/hubClient.ts — no headers on any of these
await fetch(`${hubUrl}/have`)
await fetch(`${base}/sync?since=$

[Read the thread](https://github.com/izagood/avcs/issues/50) · 2026-07-25 · closed · 0 comments

### Transport auth signs the endpoint suffix, so a signature is not bound to a repository

`hubClient` signs the endpoint suffix rather than the request's full path, so an `AVCS-Sig` credential carries no evidence of *which repository* the write was meant for. The reference hub serves one repo at the root, where this is invisible. A hub that serves many repositories under a path prefix inherits it as a real weakness.

**Environment:** avcs 0.22.0 (behaviour unchanged since transport auth landed).

## What the client signs

Every write signs a literal endpoint, not the URL it is about 

[Read the thread](https://github.com/izagood/avcs/issues/49) · 2026-07-25 · closed · 0 comments

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