Answers are grounded in this paper and cite their sources.
A large language model cannot modify a repository on its own. What a coding agent actually accomplishes depends as much on the runtime around the model as on the model itself, because that runtime brokers tool calls, confines file access, streams partial output, and asks the user for consent. This paper describes how CodingAgent was designed, built, and verified. CodingAgent is a local-first harness that runs entirely on the developer's machine and has four layers: a token-gated Hono server serving HTTP and Server-Sent Events, an agent loop built on the Vercel AI SDK, a twelve-tool execution layer with symlink-aware path confinement, and a SQLite state store. Two mechanisms carry most of the safety work. A permission mediator resolves every mutating call against an ordered policy and stores pending approvals as addressable server objects. A context injector supplies explicit, budget-limited material on each turn. The design is compared with six contemporary coding agents along four structural dimensions. Verification covers 34 API and live-streaming checks, 13 packaged-runtime checks, a clean typecheck/build/Rust pipeline, and database integrity. It also says what confinement does not do. Path checking prevents accidental workspace escape, but it is not an operating-system sandbox, because shell commands run in the host shell. The paper offers a reproducible account of the engineering decisions between an LLM and a file system, and an explicit statement of the security boundary that tool documentation usually omits.
No takes yet. Share an insight, caveat, or question.
Khairi Md.Juri (2026) studied this question.
Synapse has enriched 8 closely related papers on similar clinical questions. Consider them for comparative context: