Local AI Coding With Explicit Execution Authority

1. Locality does not decide authority

A coding assistant can operate entirely on a developer's machine and still read an unrelated file, overwrite concurrent work, or run an unexpected command. Conversely, a remote model can be used for a narrowly scoped task with a carefully bounded disclosure. Locality and authority answer different questions: where does work occur, and who permits its effects?

CodeHermit's product direction motivates a runtime that makes both answers visible. The specific problem examined here is the transition from model-generated intent to an actual workspace effect. The proposed invariant is that a model response cannot enlarge the task's granted authority. Tool availability, filesystem reach, and permission to transmit context come from the runtime's trusted policy.

The paper develops a design from that requirement and public protocol documentation. The publishing site's own validation code is not evidence of CodeHermit capabilities. No repository-wide implementation review or task-completion benchmark is claimed in this edition.

2. Separate proposal, policy, and execution

The model produces a proposed operation: inspect a file, apply a change, or request a test. A tool broker resolves that proposal against registered capabilities, validates its arguments, and checks the task's scope. An executor performs the authorized action and reports its observed result. The runtime then presents that result without upgrading “requested” into “completed.”

The Model Context Protocol architecture describes distinct host, client, and server responsibilities, including host control over connections and context. That separation provides a useful protocol-level starting point. It does not establish that an arbitrary tool server is trustworthy or that its operations are harmless. [1]

1. 1. Task scopeDeveloper intent and granted capabilities.
2. 2. ProposalModel requests a bounded operation.
3. 3. Policy checkBroker validates scope and arguments.
4. 4. ExecutionObserved effect and verification result.

A registered capability needs more than a name and parameter schema. It should declare whether it reads, writes, executes, or transmits; which resource scope applies; and what evidence identifies success. A tool named “inspect project” that executes arbitrary extensions has a different authority requirement from a bounded file reader, even if both return text.

3. Worked example: a valid edit becomes stale

Assume a developer authorizes an assistant to update a function in one source file. The assistant reads revision A and proposes a patch. While the model is generating the patch, the developer changes the same function, creating revision B.

A path-based authorization still permits a write to the file. It does not establish that the proposed bytes remain appropriate. The proposed runtime therefore includes a precondition: apply the patch only to the source version it was prepared against. The executor checks that precondition at the write boundary, not merely when the review interface opens.

If the target has changed, the runtime returns a conflict, refreshes the relevant context, and prepares a revised proposal. It should not replace B with A plus the assistant's changes. A three-way merge is an alternative, but unresolved or semantic conflicts still require another decision; a clean textual merge does not prove behavioral compatibility.

These checks produce different evidence. A successful write is not a passing test. A passing test is not permission to deploy. A readable final report should retain those distinctions without requiring the developer to inspect a raw execution transcript.

4. Context routing is a disclosure decision

A local assistant may route some tasks to a remote model for quality or resource reasons. The routing decision should account for the context that would leave the workspace. A general permission to use a provider is insufficient if the task later accumulates sensitive files outside the original disclosure scope.

The proposed runtime constructs a context manifest before transmission. It identifies the selected material, its source scope, and the applicable disclosure policy. If the context grows beyond that scope, routing must be reconsidered. The interface can explain this through a concise context preview instead of a long prompt dump.

Memory also needs its own lifecycle. A task transcript, a durable project note, and a model input have different retention and relevance requirements. Replaying every earlier message at startup consumes context and may reintroduce stale instructions. A smaller project memory should link conclusions to evidence and allow invalidation when the underlying files change.

This design trades some orchestration complexity for explainability. It does not eliminate the need to protect the local store or review provider-specific retention behavior when a remote route is configured.

5. Model and adapter identity affect reuse

Caching can reduce repeated work, but a cache key must identify the computation being reused. Prompt text alone is insufficient if behavior also depends on the base model, adapter revision, tokenizer, context transformation, or tool contract.

Consider two synthetic routes using the same task text with different adapters. A cached answer prepared under one adapter should not be silently treated as the output of the other. A useful key includes the relevant model configuration and context identity. For outputs that can cause effects, cached text must still pass current authorization and applicability checks.

This does not imply that every setting always belongs in every cache key. The implementation should document which inputs influence the cached value and validate that assumption with deliberate collisions: vary one relevant dimension while holding the visible prompt constant, then confirm that incompatible results are not reused.

The same distinction applies to tool results. A cached file read can be useful if its revision remains valid. A cached “tests passed” result is misleading after a relevant source or environment change. Caching evidence requires an invalidation model, not just a storage policy.

6. Alternatives and evaluation

A monolithic agent that directly invokes tools offers a shorter implementation path and may be sufficient for a disposable workspace with tightly limited capabilities. As authority expands, policy becomes harder to audit if it is distributed through prompt wording and tool-specific conventions.

Requiring human approval for every operation makes authority explicit but creates friction and can encourage habitual approval. The proposed broker instead supports standing permission for a bounded class of operations and requests a new decision when the class or scope changes. That approach needs careful defaults and a clear way to stop execution.

Evaluation should separate task quality from boundary enforcement. Use ordinary code-edit tasks to measure whether changes solve the requested problem. Independently inject changed target revisions, unregistered tool names, out-of-scope paths, interrupted writes, and unavailable model routes. Measure unauthorized effects directly; do not infer their absence from a successful final answer.

A useful report records proposed actions, accepted actions, conflicts, observed writes, and verification outcomes by task class. Latency should be decomposed into model time, broker time, execution, and review, with hardware and model configuration specified. This paper supplies neither those measurements nor evidence that a particular local model meets a desired quality threshold.

7. Conclusion and limitations

The proposed CodeHermit architecture treats the model as a source of proposals inside a runtime that owns authority, state preconditions, and evidence. It makes a stale edit recoverable, a remote disclosure reviewable, and a reused result traceable to the conditions that produced it.

The design still depends on the strength of its execution boundary. A broker cannot contain an executor that has broader ambient access than its contract suggests. Filesystem semantics, process isolation, extension behavior, and recovery after partial writes require implementation-specific validation. The next useful proof would be a small end-to-end edit workflow that demonstrates these boundaries under concurrent change before adding more autonomous capabilities.

References

1. Model Context Protocol. Architecture, specification dated June 18, 2025. Host, client, and server responsibilities used as a design reference in Section 2.