MLA 023 Inside a Coding Agent: Context, Instructions, Hooks, Skills, MCP

A coding agent is a loop appending to a context window, and the window is what runs out. Instruction files, permissions, hooks, skills, MCP, subagents and memory explained as one mechanism, mapped across Claude Code, Codex and OpenCode. Links Try a walking desk - stay healthy & sharp while you learn & code More OCDevel shows - this one has siblings, each on its own subject and produced the same way

Second of three episodes on coding agents: how Claude Code, Codex, OpenCode and pi handle context, instruction files, permissions, hooks, skills, MCP, subagents and memory. Claude Code is the running example; each section maps the same concept to the other three. The loop and why context is the scarce resource A coding agent is a short program: send the conversation to the model, run whatever tool it asks for, append the result, repeat until the model answers with text alone. Every appended file and test log stays in the window for the life of the session, so the context window, not the model, is what runs out. Every mechanism below is a way of deciding what enters the window and when. Compaction summarizes the history when the window fills; Claude Code's auto-compact window and /compact are configurable, and /compact is itself an expensive request while /clear is free. Thinking is dialed by effort level in Claude Code and by model_reasoning_effort in the Codex configuration reference. Instruction files: CLAUDE.md and AGENTS.md AGENTS.md has become the cross-vendor instruction file, stewarded by the Agentic AI Foundation under the Linux Foundation and read by Codex, OpenCode, Cursor, Gemini CLI, GitHub Copilot, Jules, Aider, Zed and more. Claude Code reads only CLAUDE.md, bridged with an @AGENTS.md import; the Claude Code memory docs describe the managed, user, project and local layers, lazy subdirectory loading, @ imports up to four hops, path-scoped .claude/rules/, and re-injection after compaction. Codex's AGENTS.md guide walks from the git root down with a 32 KiB default cap; OpenCode rules read AGENTS.md with a CLAUDE.md fallback plus an instructions array in opencode.json; pi concatenates AGENTS.md from home, parents and cwd. What belongs: commands, conventions and boundaries the model cannot derive from the code, under a couple hundred lines. Instruction files are context, not enforcement. Permissions and sandboxing Claude Code permissions use Tool(pattern) rules with deny over ask over allow, and the docs list how allowlists leak: absolute paths, sh -c, and unstripped wrappers like devbox run. Permission modes are default, acceptEdits, plan, the classifier-backed auto mode, and bypassPermissions. Codex separates sandbox modes (read-only, workspace-write, danger-full-access) from an approval policy. OpenCode permissions map globs to allow, ask or deny with last-match-wins. pi ships no permission system by design. Claude Code sandboxing uses Seatbelt on macOS and bubblewrap on Linux, with filesystem and network-domain allowlists. The cautionary case is PocketOS, April 2026, where a Cursor agent found an unscoped hosting token and deleted the production volume and its backups in seconds, reported by The Register and Fast Company. Hooks: deterministic guardrails at tool events A hook runs a program at a fixed point in the loop and its exit code or JSON decides what happens next; unlike an instruction, it fires every time. Claude Code hooks cover more than thirty events; exit code 2 always blocks on blockable events, PreToolUse can stop a call, Stop can refuse to end a turn, PostToolUse cannot block. Codex hooks mirror the event set and require trusting each hook definition by hash. OpenCode plugins expose tool.execute.before, permission.asked and session events; Gemini CLI hooks and Copilot CLI hooks exist too. The three worth having: a PreToolUse block on destructive commands and secret files, a post-edit formatter and typecheck that feeds errors back, and a Stop hook that holds the turn open while tests are red.