bug(mcp): maxTurns and maxSpendUSD silently bypassed on MCP-only deployments

[manzil-infinity180]

Summary

On MCP-only aflock deployments, the policy limits maxTurns and
maxSpendUSD are silently never enforced — counters stay at 0, so
neither fail-fast nor post-hoc enforcement ever fires. Found live
during PR #88 + SPIRE end-to-end testing.

Repro

With the standard MCP-UDS sandbox setup and a policy carrying real
limits:

limits:
  maxSpendUSD: { value: 5, enforcement: fail-fast }
  maxTurns:    { value: 50, enforcement: post-hoc }

After a Claude Code session running 4 tool calls, the resulting
~/.aflock/sessions/<id>/state.json shows:

"metrics": {
  "tokensIn": 0,
  "tokensOut": 0,
  "costUSD": 0,
  "turns": 0,
  "toolCalls": 4,           // ← only this counter increments
  "tools": { "Bash": 2, "Read": 2 }
}

Why it happens

• RecordAction (called from internal/mcp/server.go:1379) increments
  ToolCalls and Tools map ✅
• IncrementTurns / UpdateMetrics(tokensIn, tokensOut, costUSD) are
  ONLY called from internal/hooks/handler.go:668 ❌
• The MCP path has no equivalent observable for either:
  • Tokens / cost: MCP protocol doesn't carry Claude's model usage
    telemetry. aflock cannot see how many tokens Claude used to process
    a request — that information only reaches us via the
    claude-code PostToolUse hook.
  • Turns: MCP has no "turn boundary" signal. One user message can
    trigger N tool/call requests; aflock sees the individual requests
    but not the boundary.

Why this is security-relevant

Verify-time and fail-fast enforcement of maxTurns and maxSpendUSD
are both bypassed silently. Policy authors writing these limits have
no way to know their constraints are unenforced on the deployment
shape they're using.

Fix options

Option A — Refuse-or-warn at startup (smallest)

At MCP server start, inspect the policy. If either maxTurns or
maxSpendUSD is set, and we are running MCP-only (no hooks active in
the same process), either:

1. Refuse to start (fail-fast enforcement is impossible to honor)
2. Log a loud warning (post-hoc could still be honored later)

Pros: small (~50 lines + tests). Closes the silent-bypass UX trap.
Cons: doesn't actually make the limits work.

Option B — Heuristic counters

• Increment turns per tools/call request on MCP path. Overcounts
  vs hooks path's "turn = user message" definition, but better than 0.
• Estimate costUSD from response payload sizes. Very approximate.

Pros: limits become somewhat enforceable.
Cons: numbers are misleading; "turn" no longer means the same thing
across deployment shapes; encourages false sense of safety.

Option C — Hybrid deployment

Recommend running both MCP + hooks in the same session. Hooks path
provides accurate metrics; MCP path provides identity attestation.
Document the requirement and provide a config flag.

Pros: zero approximation.
Cons: complexity for users; adds a setup step.

Option D — Upstream MCP extension

Propose to Anthropic that MCP carry usage metadata in tool/call
results (similar to how the Anthropic API returns usage with each
response). Long-term proper fix.

Suggested next step

Land Option A as a near-term mitigation — it closes the silent
bypass, even if it doesn't make the limits work. Track Options B/C/D
as separate issues once Option A ships.

Files of interest

• internal/mcp/server.go — server start, policy load
• internal/state/session.go:237 (UpdateMetrics),
  :247 (IncrementTurns) — only called from hooks
• internal/hooks/handler.go:668 — the only call site

Acceptance for Option A

• Starting aflock serve --unix with a policy containing maxSpendUSD
  with enforcement: fail-fast refuses to start with a clear error
  pointing to this issue
• enforcement: post-hoc logs a warning at startup but allows start
• Same behavior for maxTurns
• Regression test asserts both behaviors

[manzil-infinity180]

Update — original framing was too pessimistic

Researched this further and the architectural premise of this issue ("MCP transport cannot observe these metrics") is not actually correct.

Claude Code writes a session JSONL at ~/.claude/projects/<encoded-cwd>/<session-uuid>.jsonl after every assistant turn, and every line includes the full usage block from the underlying Anthropic API response:

"message": {
  "usage": {
    "input_tokens": ...,
    "output_tokens": ...,
    "cache_read_input_tokens": ...,
    "cache_creation": { ... }
  }
}

This works identically on Claude Max subscription and API-key Claude Code — the usage field is populated regardless of auth mode, and a whole community ecosystem (ccusage, claude-usage, token-dashboard, etc.) is built on tailing this file.

aflock already locates this file today — see [aflock] Most recent session file: … log at server start. It just doesn't parse the usage field yet.

So the correct frame is: "these metrics are not currently parsed, but they're observable."

Implication for fix path

The four options in the original issue body are still valid, but Option B ("heuristic counters") was wrong — we don't need to estimate; we have the real data. Replacing it with:

Option B' (revised) — JSONL-based token tracking. Parse message.usage from the session JSONL on PreToolUse / MCP-server-tail. This is what other tools do. Filed as #96.

PR #95 (the startup gate) was closed in favor of going straight to the proper fix.

Status

• Closing PR fix(mcp): refuse fail-fast / warn post-hoc on limits MCP cannot enforce #95 ✅
• Tracking the proper fix as feat: implement token/cost/turn tracking via Claude Code session JSONL #96
• Keeping this issue open as the architectural-context ticket; close once feat: implement token/cost/turn tracking via Claude Code session JSONL #96 ships and metrics are populating correctly.

[manzil-infinity180]

Superseded by #96 (proper JSONL-based token tracking). The original framing here turned out to be wrong — see the previous comment for the architectural correction. Closing this so #96 is the single source of truth for the work.