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