standing agents with one job each, beside your main chat

Pips are standing agents that work beside your main DGC chat. A Pip has one job, written in plain words, and keeps it: reviewing a project's committed code every morning, running a fixed set of test commands, drafting documentation, or helping you with your own day. Everything a Pip does that matters is a proposal you review first. The full guide is docs/PIPS.md.

A Project Pip belongs to one Git project and reads its committed source: Scout explores, Lens researches a question, Rook reviews, Lock looks for security issues, Quill drafts documentation, Patch prepares a fix in a private copy, Pulse runs the exact commands you reviewed. A Personal Pip belongs to your DGC profile and helps with errands, plans and replies.

Open the Pips view with the Pips button in the DGC chat view's title bar, or ask the main chat: "Review committed changes in this project every weekday at 9:00, and run once now." In the terminal, dgc pips does the same (dgc pips create, list, run, stop, ...).

The main chat also knows your Pips' models. Ask which models your Pips can use (each with the context window DGC starts it with), or to change one: a Pip's model or context window, a Personal Pip onto your own Claude Code or Codex, or the model every Pip on Default uses. It asks you before each change, and a model or window never changes what a Pip may do. A new Pip it sets up gets a model and window that fit its job, with one line on why; change them on the card or the Pip's page.

Pips run on your computer, in the runner, with no Pips account and no hosted service. Keep Pips running (the Pips view's runner controls, or dgc pips keep-running on) starts the runner when you log in, so a morning schedule still runs after a restart; DGC turns it on the first time a Pip gets a schedule, a commit trigger or a routine. Up to four Pips work at once, with no daily token limit. On a server with no desktop, run dgc pips serve --server (or the Docker image in deploy/docker) beside your app, and dgc pips health says whether it is running; there, Pips use an API key or a self-hosted model, never your Claude Code or Codex plan.

• A Pip speaks for its runs. Each finished run is a message from the Pip in its own chat, in short first-person words made from the run's report alone, so every number, file and title it says is the report's: "I found 4 issues, 3 of them serious." All-clear runs in a row fold into one message that updates itself. Reply to it there. After Ask DGC to fix, that message says how the fix is going: DGC is fixing this, Fixed · 3 files (a click opens its card in the Work chat, with Review and Undo), or that it didn't finish, with Ask DGC to fix again. While a run goes on, it is already there: one message with the Pip at work, what it is doing now, a clock, Stop and how it started (Started by you, On schedule · 9:00 AM, Asked by DGC, First run), which becomes its report in the same place when the run ends. A Project Pip's page is a Personal Pip's: its chat under a top bar with Run now, and History, Settings, Schedule, Handoffs, Changes, Memory, Context and Notifications in its … menu.
• Reports reach your chat. A project reviewer's finished run appears as a card in the chat it reports to: what it found and the worst of it, with Open report. A card never starts a turn. Ask DGC to fix starts a helper in the chat's session without starting a turn, so you keep chatting. It works in one copy of the project DGC keeps for fixes, with the project's own install, and runs the tests there when it can. The card is its live status (Watch, Stop, and a question it needs asked right on the card); then what it changed and whether the tests ran in the copy, with Review and Undo. A file you changed on the same lines meanwhile is held back. A Pip fixes chip on the chip line above the message box lists the fixes while they work.
• Routines. A Personal Pip does things on its own at a time, on a new email that matches a search, before a calendar event, or when your own app sends an event ("when the shop app sends order.created"): once for each event, with what the app sent as data, never as instructions. It suggests one as a card; nothing runs until you add it. Your app's code sends the event with the SDK's pips.trigger, which only starts what you set up.
• Pips your code keeps. Your own app's code can declare Personal Pips in code (the SDK's PipTemplate and pips.ensure_all) and keep them as declared on every deploy. Such a Pip says From your code on its page and uses only the app tools its template lists. Narrowing changes apply by themselves; anything that lets it do more (a new change tool, asking less, Always allow, a routine on your app's event) waits on its page as Your code asks to let it do more, with Accept and Not now. What you change on the Pip yourself stays as you set it.
• Live data. A Pulse can keep an eye on live data instead of running tests: a short list of exact read-only command lines you approve (a SELECT through a read-only database account, df -h ., curl -s http://127.0.0.1:8000/health). DGC runs only those lines, in a read-only box in your project folder, and its model sums up what they printed; every number in the summary comes from the output. The box reaches only the local addresses the lines name and the project's read-only database. A line with an obvious write is refused when you approve the list and again before a run, and changing the list is a reviewed change. The summary posts in the Pip's chat and reaches your Work chat as a report: "all clear", or "needs you" with Ask DGC to fix. Ask the main chat to set one up, or choose Read-only commands on live data in a Pulse's Plan & schedule. Use a read-only database account: dgc readonly-db guide shows how to make one. It runs on Linux with bubblewrap, on a Mac under Seatbelt (a little weaker, as its card says) and on Windows in DGC inside WSL 2; elsewhere the Pip says why its commands can't run.

Every new Personal Pip gets its own computer: a browser and files in a sandbox, apart from yours, on Linux, in WSL 2 and on Apple-silicon Macs with macOS 26 or later. A Pip whose model can see uses the whole desktop on Linux (browser, Files, Terminal, an image editor, Documents and a PDF viewer); on a Mac it works in its browser.

• How much it asks. Each Personal Pip has a level you set on its page: Ask (every submit and send waits for you), Approve for me (routine steps such as a search, adding to a cart or saving a draft go by themselves; orders, posting, deleting and sending to someone new still ask) or Full access. New Pips start at Approve for me. Payments ask at every level.
• Always allow lets one exact kind of action through from then on, for the same account, tool or site; its page lists them, with Stop allowing. A payment never offers it.
• Saved logins. Save a site's login once, with its authenticator key if it has one, and DGC types it in, the one-time code too. The Pip never sees it.
• Borrowing your Chrome. For one task that needs a site you're signed in to, a Pip can ask to use your own Chrome. Allow once (Chrome asks too), and it works in a tab of its own, on the card's sites only, then gives your Chrome back. It asks every time; there is no Always allow.
• You type the card. Asked to pay, it fills in everything but the card and asks you to type it on its screen and press Pay. A card number sent in its chat isn't sent.

• Your Claude Code or Codex. A Personal Pip can think with the Claude Code or Codex you're signed in to, on your own plan. Their own tools stay off: the Pip's tools and rules come from DGC.
• Working notes and a daily log. It keeps short notes on how its job goes, which you can edit; DGC writes a daily log of its runs for you. What you tell it about yourself shows as Remembered, with Forget. /learn in its chat turns what it just did into a skill you save.
• Apps and plugins. Connect Gmail or a calendar from its chat; every plugin you turned on in Settings is every Pip's to use, and for each one you choose what it may do without asking, from Always ask to Never ask. A plugin that can move money always asks.

Linux and macOS, and Windows with DGC inside WSL 2: there, Windows starts the runner when you sign in, notifications are Windows' own, and your signed-in Chrome is the one on Windows. Patch and Pulse commands run under bubblewrap on Linux and Seatbelt on macOS, which DGC tells you is weaker; so do a live-data Pip's commands and a Troupe checker's shell, in a read-only box that on a Mac is a little weaker too: a command there can see which other programs are running, and Apple marks sandbox-exec as deprecated. Pause one Pip, or stop them all with dgc pips stop. From your own program, the SDK's session.pips manages the Pips of your profile; see SDK.