loopndroll: a local hook that keeps Codex working instead of stopping

The problem is an agent that stops while the job is unfinished

loopndroll's pitch is a single sentence: let Codex run until the task is actually done. The README describes the frustration in the first person, about having to send dozens of follow-up messages just to keep Codex running, or about feeling frustrated when it skipped tests, lint, or typecheck even though you clearly asked for them in Agents.md. The tool is built on three capabilities: keep Codex running until you stop it, require specific commands at the end of a task and keep going until they pass, and get progress updates in Telegram or Slack, with the ability to reply to redirect the work or change the mode. The audience is a developer supervising an agent over a long task, and the assumption is that the agent will stop early, which is the behaviour the whole tool exists to correct.

It works through Codex Hooks at the moment the agent tries to stop

The mechanism is small and precise. Loopndroll plugs into Codex through Codex Hooks. When a chat starts, Loopndroll registers it and remembers the settings for that task. When Codex tries to stop, Loopndroll gets a chance to decide what should happen next. Depending on the mode, it can let the chat stop, send another prompt and keep Codex going, run the completion checks first and keep going if they fail, or wait for a reply from Telegram and feed that reply back into the same chat. In parallel it can send the latest assistant message to Telegram or Slack, so you see progress without sitting in front of Codex. The interception point is the key design decision, because it means the tool does not have to drive the agent loop itself, it only has to act at the moment the agent would have finished.

Four modes, and no mode means Codex stops normally

You can set a mode globally for all chats, or override it per task, and if no mode is active Codex stops normally. Infinite sends the default follow-up prompt every time Codex stops and keeps the chat going, with the default prompt changeable in Settings or overridable for one task by replying to that task in Telegram. Await Reply waits for your reply in Telegram when Codex stops and then sends that reply back into the same chat. Completion Checks runs your commands, like tests, lint, or typecheck, and tells Codex to keep going if any command fails. Max Turns 1 / 2 / 3 keeps Codex going for a fixed number of extra turns and then lets it stop. The README frames these as a simple choice between pushing automatically, waiting for human input, requiring checks to pass, or allowing only a small number of extra turns, and the Max Turns modes are the one that offers a bound.

Completion Checks is the mode that matches a real CI pipeline

The use cases section maps each mode to a specific frustration, and the second one is the most concrete. When you want Codex to stop only after the repo is actually green, you use Completion Checks, and the README describes the case as the common one where the agent says it is done but tests, lint, or typecheck still fail. The example it gives is making sure `pnpm test` passes before marking the task as done. Infinite is described as the right choice for the opposite situation, where the work is real but there is no clean automatic way to evaluate done yet, which fits cross-file refactors, bug hunts, and long review-comment cleanup where the next step depends on what the agent finds. Await Reply covers the third case, where you want to review a draft, approve a plan, or redirect the work while away from your desk.

Notifications use your own bot, and the app never proxies your chats

The privacy claim is specific and worth checking against the setup instructions. Loopndroll runs fully locally on your machine and does not send your chats, prompts, or app data to any Loopndroll server, and if you connect Telegram or Slack you are using your own bot or your own webhook, under your control. The Telegram flow starts with BotFather, where you send `/newbot` and receive a token that looks like `123456789:AA...`, which you paste into `Settings` -> `Notifications` -> `Add Notification` under `API Token`. To get a chat to appear in the app you message the bot directly or add it to a group and send any message, then pick the chat from the `Chat` dropdown. For Slack the README is emphatic that the app uses a Slack Incoming Webhook URL and does not use a Slack bot token, so if you were looking for a token, this app does not need one.

Telegram doubles as a remote control for the agent

The Telegram command set is the part that turns a notification channel into an input channel. After a bot is connected, the commands work in Telegram: `/help` shows the command help, `/list` lists the chats registered to that Telegram destination, `/status` shows the current global mode and the per-chat modes, and `/reply C22 your message` sends a message to one specific chat. The `/mode` command takes either `global` or a chat identifier followed by `infinite`, `await`, `checks`, or `off`, so the global mode and a per-chat override are the same command with a different target. Two notes on the ergonomics. If you reply directly to a Telegram notification, Loopndroll uses that chat automatically, and if you send plain text without a command, it goes to the latest waiting chat in that conversation.

The app is a Bun and Vite desktop client, and it ships as a DMG

The repository layout shows a TypeScript desktop application built on Electrobun with a Vite renderer, which is visible in the scripts. The `dev` script runs Vite and the Electrobun app together with `concurrently`, the HMR server is Vite bound to `127.0.0.1` on port 5173 with `--strictPort`, and the build pipeline is `vite build` followed by `electrobun build`, with a `--env=stable` variant for the release build and a shell script for the macOS release. The download link in the README points at a `stable-macos-arm64-Loopndroll.dmg`, so the packaged artefact is an Apple Silicon disk image. The UI stack is React 19 with Tailwind, shadcn, and a set of Radix-style base components, with drizzle-orm and zod for persistence and validation, and the quality gate is a single `check` script that runs lint, format check, and typecheck in sequence. The `.env.example` file shows the release base URL and the codesign and notarize toggles.

Where loopndroll is the wrong choice

Two limits are visible in the README. The first is that this is a supervisor for a specific agent, not a general harness. It plugs into Codex through Codex Hooks, and the modes are named in terms of that agent's behaviour, so a team using a different coding agent gets nothing from it without writing the equivalent hook integration. The second is that Infinite mode is a blunt instrument by design. The README recommends it for the case where there is no clean automatic way to evaluate done, which is honest, and the consequence is that a mis-specified follow-up prompt can push an agent through a long loop of changes with no external check on whether it is improving. The Max Turns modes exist to bound that, and the Completion Checks mode exists to replace judgement with a command. If neither a check nor a turn limit is meaningful for your task, then the tool is asking you to supply a supervision policy you do not have, and that is the honest reason not to use it.

Editorial conclusion

loopndroll fits a developer who drives Codex on long tasks, loses the thread while it works, and wants either a green test suite or a human decision before the agent is allowed to stop. It is the wrong tool if you want an agent that finishes on its own without a supervisor, since the Infinite mode is explicitly the option for work where there is no clean automatic way to evaluate done. Before you adopt it, read the modes list and pick one deliberately, because the default is that Codex stops normally, and set up Telegram or Slack only if you actually want the notifications, since the completion checks need no chat integration at all.

Frequently asked questions

Official sources

1. Issues
2. lnikell/loopndroll on GitHub
3. README
4. Releases