# 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](/mcp/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__<server>__<

[Read the thread](https://github.com/arthurpanhku/dvalincode/issues/52) · 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](https://github.com/arthurpanhku/dvalincode/issues/49) · 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](https://github.com/arthurpanhku/dvalincode/issues/137) · 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](https://github.com/arthurpanhku/dvalincode/issues/53) · 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](https://github.com/arthurpanhku/dvalincode/issues/119) · 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](https://github.com/arthurpanhku/dvalincode/issues/56) · 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](https://github.com/arthurpanhku/dvalincode/issues/55) · 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](https://github.com/arthurpanhku/dvalincode/issues/54) · 2026-07-02 · open · 0 comments

## Most recent

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