Search ARuntime.com

Find runtime definitions and implementation guidance

Search page titles, summaries, headings, glossary terms, use cases, and runtime-directory entries.

Enter at least two characters.

ARuntime Reference

Coding Agent

Prepare and validate repository changes inside a scoped workspace without granting uncontrolled command or secret access.

Audience: Technical readers Reading time: 3 minutes Status: Production guidance Last reviewed:

Prepare, test, and review bounded repository changes without granting uncontrolled command, secret, or deployment access.

Key takeaways

  • Primary risk: Arbitrary command execution, secret leakage, supply-chain changes, duplicate writes, and unsafe deployment.
  • Keep authoritative domain state outside model memory.
  • Measure task outcome, safe failure, and evidence—not output fluency alone.

Problem

Prepare, test, and review bounded repository changes without granting uncontrolled command, secret, or deployment access.

Principal risk: Arbitrary command execution, secret leakage, supply-chain changes, duplicate writes, and unsafe deployment.

Why runtime layers are needed

A single model invocation cannot reliably own identity, authorization, durable state, external side effects, recovery, or evidence. The runtime composes the necessary compiler/inference/serving path with application controls appropriate to this use case.

Reference architecture

  • Repository authorization broker and branch/worktree boundary
  • Scoped source/context selector
  • Model route and patch generator
  • Isolated command sandbox with constrained network egress
  • Typed repository, dependency, test, and artifact tools
  • Diff, test, policy, and approval evidence
  • CI/CD and production deployment outside default agent authority

Request flow

  1. Resolve repository, branch, actor, issue, allowed paths, and write policy.
  2. Select only required source, policy, and dependency files.
  3. Generate a patch proposal without deployment authority.
  4. Validate paths, diff size, dependency allowlist, and prohibited secret files.
  5. Apply in an isolated branch or worktree with an idempotent operation key.
  6. Run formatters, static checks, tests, and security scans under resource limits.
  7. On failure, restore checkpoint or revise within attempt budget.
  8. Present diff, commands, tests, sources, risks, and rollback for approval.
  9. Merge, release, or deploy only through separately authorized tooling.

Contracts

  • Runtime request binds repository, commit, allowed paths, command classes, network destinations, budgets, and approval.
  • Command tool contract uses executable plus structured arguments rather than a shell string.
  • Patch tool contract records base commit, target paths, diff hash, and reversible branch operation.
  • Evidence record links tests and artifacts without storing repository secrets.

Use the runtime request, tool, policy and approval, evidence, and trace schemas as versioned reference boundaries.

Failure modes

  • Prompt injection in source comments or issue text
  • Command escapes sandbox or writes outside workspace
  • Dependency resolver contacts an unapproved registry
  • Base branch changes after context selection
  • Tests are flaky or environment-specific
  • Tool times out after a partial file write
  • Patch passes tests but violates product or security policy

Security considerations

  • Use least-privilege repository tokens and short-lived credentials.
  • Default-deny network egress except approved package and source endpoints.
  • Mount secrets only for a specific tool and never into model context.
  • Block direct production deployment and protected-branch write by default.
  • Scan generated artifacts and dependencies before approval.

Observability

Correlate request, model route, context sources, tool operations, policy decisions, approvals, artifacts, failures, recovery, and domain outcome. Apply redaction and retention before exporting traces.

Evaluation and metrics

  • Patch acceptance rate
  • Test and static-analysis pass rate
  • Unauthorized command/path attempts
  • Rollback success
  • Duplicate-write prevention
  • Human review time
  • Regression/incident rate after merge
  • Evidence completeness

Implementation checklist

  • Define allowed repositories, branches, paths, commands, and egress.
  • Use isolated workspaces and non-root execution.
  • Require base-revision checks before applying or merging.
  • Test worker termination around every write.
  • Preserve patch, test, source, and policy evidence.
  • Use deterministic codemods for fully specified transformations.

Maintenance record

Found an error, outdated capability, or unclear category boundary? Submit a correction with a supporting source.