Coding Agents
Coding agents give your MeetLoyd agents the ability to clone repositories, write code, run tests, commit, push, and open pull requests — all inside isolated sandbox environments. Every LLM provider is supported (Claude, GPT, Gemini, Mistral, Groq, self-hosted models), so there is no provider lock-in.
This guide covers setup, the coding lifecycle, security, CI integration, and cost controls.
Overview
Coding agents combine three capabilities:
- Coding Tools — read, write, edit files, search code, and run commands
- Git Tools — full git lifecycle: clone, branch, commit, push, PR, CI status
- Sandbox Isolation — all operations run inside a sandboxed project directory
Getting Started
1. Connect a Git Integration
Go to Settings > Integrations and connect your GitHub or GitLab account. This triggers automatic discovery: available coding tools are identified, the coding-agent skill is suggested for relevant agents, and agent memory is updated with the new capabilities.
2. Assign the Coding Agent Skill
Navigate to Agents > [Your Agent] > Skills, find coding-agent in the catalog, and click Assign. This unlocks 16 tools:
| Category | Tools |
|---|---|
| Files | File read, file write, file edit, search, list files |
| Commands | Bash execution |
| Git | Status, clone, checkout, diff, add, commit, push, log |
| Pull Requests | PR create, PR status |
3. Start a Coding Session
Tell your agent what to build or fix. The orchestrator handles the full lifecycle automatically:
Clone repo > Create branch > Write code > Run tests > Commit > Push > Open PR > Monitor CI
If CI fails, the agent automatically reads the error output and fixes the issues (up to 3 retry attempts).
LOYD.md — Project Constitution
When an agent starts working on a repository for the first time, MeetLoyd automatically generates a LOYD.md file — a model-agnostic project constitution that provides coding context.
LOYD.md is created by scanning the repository for approximately 80 marker files (package.json, Cargo.toml, go.mod, tsconfig.json, CI configs, Dockerfiles, and more). The tech stack, frameworks, build tools, test runners, and linting configs are identified, then synthesized into a structured document with 9 sections:
| Section | Content |
|---|---|
| Project Overview | What the project does |
| Tech Stack | Language, framework, build tool, test runner |
| Project Structure | Directory layout and key files |
| Development Commands | How to build, test, lint, and run |
| Coding Conventions | Style rules, naming, formatting |
| Architecture Patterns | Design patterns in use |
| Testing Strategy | How tests are organized and run |
| CI/CD Pipeline | Continuous integration and deployment |
| Security Considerations | Security-relevant patterns |
If your repo already has a CLAUDE.md or LOYD.md, the agent uses that instead of generating a new one.
Security
Sandbox Isolation
All file and command operations are sandboxed:
| Protection | Details |
|---|---|
| Directory confinement | Files can only be accessed within the project directory |
| Path escape prevention | Attempts to access files outside the allowed scope are rejected |
| Sensitive path protection | Configuration files and system directories are inaccessible |
| Command safety | Destructive or dangerous commands are blocked |
| Network isolation | Network access disabled by default unless explicitly allowed |
Git Security
| Protection | Details |
|---|---|
| Shell injection prevention | All user inputs are sanitized |
| Branch/remote validation | Names must match a strict alphanumeric pattern |
| URL validation | Only HTTPS, SSH, and git protocols accepted for clone |
| No interactive prompts | Credential dialogs are suppressed |
| Diff size cap | Output limited to 50 KB to prevent context flooding |
Approval Gates
Operations that modify the remote repository require approval in proactive mode:
| Tool | Requires Approval |
|---|---|
| Clone | Yes |
| Commit | Yes |
| Push | Yes |
| PR create | Yes |
| Bash execution | Yes |
| All other tools | No |
Audit Trail
Every operation is logged with timestamp, tool name, action, path, and whether it was allowed or blocked.
Autonomy Levels
The coding orchestrator respects MeetLoyd's standard autonomy model:
| Level | Behavior |
|---|---|
| Autonomous | Agent clones, codes, commits, pushes, and creates PRs without asking |
| Proactive (default) | Agent does the work, then asks for approval before commit/push/PR |
| Reactive | Agent waits for explicit instructions at each step |
Cost Controls
A cost guard checks accumulated LLM costs before each coding iteration:
| Setting | Value |
|---|---|
| Default limit | $5.00 per session |
| When reached | Coding loop stops gracefully |
| Work preserved | Changes can be committed manually |
| Tracking | Real-time via the executor's token usage reporting |
CI Integration
After pushing and creating a PR, the agent monitors CI checks:
- Polls CI status every 15 seconds
- Waits up to 5 minutes for CI to complete
- If CI fails, reads the error output and enters a fix loop
- Fix loop: code changes, commit, push, wait for CI
- Up to 3 retry attempts
| CI Provider | Support |
|---|---|
| GitHub Actions | Fully supported |
| GitLab CI | Fully supported |
Connector Screening
When you connect any new integration (not just GitHub), MeetLoyd runs a connector screening:
- Tool Discovery — identifies what tools are now available
- Data Discovery — connector-specific introspection (e.g., CRM pipelines, repo structure)
- Memory Update — stores discovered capabilities in agent memory
- Skill Suggestion — recommends relevant skills for the new integration
This happens automatically, not just during initial team setup. Connect a CRM months later and your agent immediately learns what data is available.
Supported Git Providers
| Provider | Clone | Push | PR Creation | CI Status |
|---|---|---|---|---|
| GitHub | HTTPS, SSH | Yes | Yes | Yes |
| GitLab | HTTPS, SSH | Yes | Yes | Yes |
| Bitbucket | HTTPS, SSH | Yes | Manual | Manual |
PR creation and CI status checking for GitHub and GitLab require the gh or glab CLI to be installed and authenticated in the sandbox environment.
Example Workflow
Here is what happens when you tell your agent "Fix the login validation bug in our webapp":
- Agent receives the task
- Orchestrator provisions a sandbox microVM
- Repository is cloned, a feature branch is created
- LOYD.md is generated (or loaded from repo)
- Agent reads relevant files and understands the codebase
- Agent makes targeted code changes
- Agent runs tests to verify the fix
- Changes are committed and pushed
- A pull request is created (as draft if configured)
- CI checks are monitored
- If CI fails, agent reads errors and fixes them
- Sandbox is cleaned up
- You receive the PR URL for review
The entire flow is visible in the team activity feed.