Other formats agents might prefer:
markdownjsonllms.txt

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

Reported issues for dvalincode

Pod holds 8 of 8 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 dvalincode.

Most discussed

feat: stdio / local MCP servers (governed)

Why (roadmap: Next)

Governed MCP v1 (docs/GOVERNED-MCP.md) covers remote Streamable HTTP servers. Local stdio servers complete the story — many MCP tools run locally, and stdio avoids network egress entirely.

Sketch

  • Spawn the server as a child process through runGovernedProcess (sandbox + policy) — never a bare spawn (see the governance rules in CONTRIBUTING).
  • Same JSON-RPC methods as src/mcp/client.ts but over stdin/stdout framing.
  • Same governed mapping: `mcp____<

Read the thread · 2026-07-02 · closed · 3 comments

docs: fully annotated dvalin.policy.json example

Context

The policy engine supports modes, providers, models, commands (allow/deny/defaultDeny), paths, tools.deny, mcp.allow, network levels, and maxToolCalls (src/core/policy.ts). There is no single reference example showing every field with comments explaining semantics — especially narrowing (repo can only tighten machine policy) and the three network levels.

Sketch

  • docs/POLICY-REFERENCE.md: one complete annotated example + a field-by-field table + 3 recipes ('locked-down finance

Read the thread · 2026-07-02 · closed · 2 comments

feat: parse + Zod-validate local stdio MCP server config entries (first slice of #52)

Good first issue — a self-contained first slice of #52 (governed stdio / local MCP servers). A maintainer will help you land it; comment to claim.

Goal

Add parsing + Zod validation for local (stdio) MCP server config entries, shaped { id, command, args, enabled }, alongside the existing remote-server config. This is pure config plumbing — no process spawning, no transport (those are the hard, governance-heavy parts and stay in #52).

Where

  • MCP config: src/mcp/config.ts

Read the thread · 2026-07-22 · closed · 1 comment

feat: structured approval grants (beyond boolean approve/deny)

Why (roadmap: Next)

Approvals today are per-call booleans (requestApproval(id, toolName, input)). Regulated teams need scoped grants: who approved what, for which scope, until when — recorded as evidence.

Sketch

  • Grant shape: { subject, toolName, scope (e.g. command pattern/path glob), expiresAt | forRun }.
  • 'Allow npm test for the rest of this run' instead of clicking approve N times.
  • Grants checked at the registry.run chokepoint after policy; every grant + use record

Read the thread · 2026-07-02 · open · 1 comment

test: harness-mode + unattended-tier coverage

Why

src/harness/run.ts (executeHarnessRun) is the headless entrypoint (docs/HARNESS-MODE.md) and is currently only exercised indirectly via tests/mcp/server.test.ts and tests/commands/run.test.ts. There's no tests/harness/ and, critically, no dedicated test pinning unattended-tier behavior — the most governance-sensitive path, since it runs without a human in the loop.

Sketch

  • tests/harness/run.test.ts driving executeHarnessRun directly: happy path, policy-denied to

Read the thread · 2026-07-18 · open · 0 comments

feat: anchor MCP discovery egress into the per-run audit chain

Why (roadmap: Next)

Per docs/GOVERNED-MCP.md (deferred item): MCP tool calls are audited against the live per-run sink, but the pre-run discovery connection (initialize / tools/list in registerMcpServers, src/agent/session.ts) runs before the run's AuditSink exists — its egress is enforced but not recorded in the run chain.

Sketch

Options (design discussion welcome):

  1. Buffer discovery mcp_request events and append them right after run_start.
  2. Record a per-session discove

Read the thread · 2026-07-02 · open · 0 comments

feat: govern the remediation worktree git calls (close the documented exemption)

Why (roadmap: Next)

src/remediation/worktree.ts runs two local git commands via direct execFile — a documented exemption in docs/EGRESS-THREAT-MODEL.md ('Remediation subprocesses'). Closing it requires teaching the sandbox profile about the remediation directory first: Seatbelt/Bubblewrap currently only grant file-write to the workspace cwd + /tmp + /var, while worktrees are written under ~/.dvalincode/projects/remediations.

Sketch

  • Extend buildLaunch in `src/core/subprocessSan

Read the thread · 2026-07-02 · open · 0 comments

feat: read-only Explore subagent with inherited policy + linked audit chain

Why (roadmap: Next)

Complex tasks benefit from parallel read-only exploration. Full autonomous subagents multiply the governance surface, so v1 is deliberately read-only.

Sketch

  • A task-style tool that spawns a child run restricted to read tools (read_file, search_text, list_files, git_*, memory read).
  • Child inherits the parent's resolved policy automatically (never re-resolves wider).
  • Child gets its own audit chain whose run_start carries the parent runId — same linking

Read the thread · 2026-07-02 · open · 0 comments

Most recent

The remaining reports are on the project's issue tracker.