https://github.com/ferrislucas/Circus-Chief

Full disclosure: it’s my project

https://github.com/ferrislucas/Circus-Chief

Circus Chief is a tool for managing coding agent sessions from a browser. It's specifically optimized for small screens. It supports Claude Code, OpenAI Codex, and Google Gemini CLI agents.

Features

Agents can operate Circus Chief itself. Agents can spawn sessions, schedule sessions, interact with the Kanban board — anything you can do in the UI, an agent can also do.

Schedule work ahead of time.

Automatically reschedule when you hit usage limits.

Configurable, chainable prompt templates.

User-defined commands - agents can run them and see the results, and so can you in the UI. Handy for local CI or routine workflow steps.

Worktree-per-session isolation, or elect to work on a specific branch.

Shared canvas - this is a place for shared artifacts that don't belong in the code. Useful for iterating on planning documents.

Bring your own provider. Use subscription auth for Anthropic, OpenAI, or Google, or point sessions at third-party providers with Anthropic- or OpenAI-compatible endpoints.

If you want to try it:

  npx circuschief

Circus Chief is a tool for managing coding agent sessions from a browser. It's specifically optimized for small screens. It supports Claude Code, OpenAI Codex, and Google Gemini CLI agents.

Features

Agents can operate Circus Chief itself. Agents can spawn sessions, schedule sessions, interact with the Kanban board — anything you can do in the UI, an agent can also do.

Schedule work ahead of time.

Automatically reschedule when you hit usage limits.

Configurable, chainable prompt templates.

User-defined commands - agents can run them and see the results, and so can you in the UI. Handy for local CI or routine workflow steps.

Worktree-per-session isolation, or elect to work on a specific branch.

Shared canvas - this is a place for shared artifacts that don't belong in the code. Useful for iterating on planning documents.

Bring your own provider. Use subscription auth for Anthropic, OpenAI, or Google, or point sessions at third-party providers with Anthropic- or OpenAI-compatible endpoints.

If you want to try it:

  npx circuschief

Development process

I built this almost entirely from my phone and tablet — starting with Claude Code using both Anthropic and z.ai, then adding Codex to the mix around a month ago.

It was vibe coded in the sense that I was not reviewing many individual lines of code. I did review and iterate on plans with the agents, but often stayed out of implementation details. If a plan made sense then I would usually have the agent review it a few times before just letting the agent implement without any intervention. I've enjoyed building this way, but I don't deeply understand a lot of the details of the implementation. That's bitten me exactly once so far, see this issue: https://github.com/ferrislucas/Circus-Chief/issues/944

I used Circus Chief to build Circus Chief from a very early stage. I bootstrapped with Vibe Kanban, then switched to dogfooding once Circus Chief was usable. A lot of the app has been built through the app itself.

By the numbers

2,184 agent sessions since Christmas 2025 — 1,423 were child/follow-up sessions.

Agent mix: 1,818 Claude Code sessions, 363 Codex sessions, and 3 Gemini sessions.

50,929 conversation messages across those sessions.

41 sessions (1.9%) contained strong profanity in user-authored messages.

990 sessions linked to GitHub PRs, across 685 distinct PRs, 759 branches, and 731 worktrees.

Average logged agent call: 131.3 seconds.

2,410 commits on main; 883 pull requests total — 847 merged (~96%).

Repo scale: 887 tracked files and 310K current lines of code (excludes lockfiles, fixtures, and recorded test cassettes).

Peak day: 76 commits on March 21, 2026, first at 12:49am, last at 11:57pm — one every 18 minutes for 23 hours.

Busiest merge day: 28 pull requests shipped — New Year's Day, 2026.

Largest PR by diff: 140K insertions across 92 files — replacing mock Claude fixtures with VCR-style record/replay.

Code: https://github.com/ferrislucas/Circus-Chief

Analytics disclosure: the npm build includes PostHog for anonymous page-view analytics (session recording off, DNT respected). Disable with --no-analytics, in Settings → General, or build from source without a PostHog key.

Comments URL: https://news.ycombinator.com/item?id=48370360

Points: 4

# Comments: 0

I’m curious what your thoughts are around Cursor, Windsurf, etc. Those are IDE’s that provide the model with limited access to the terminal. Where do you feel like those tools and their AI features - terminal access specifically, fall in an org like yours? Are they disallowed due to terminal access or are the limitations of those tools safe enough?

Would you mind elaborating if I misunderstood what you meant?

We’re 100% on the same page here. No one should ask Claude (or any model) to do something using their terminal and then just walk away. I hope that’s clear from the safety section of what I posted (and in the project README).

Claude REALLY wants to help, and it will go on a journey to the end of the earth to accomplish your task. If you delegate tasks to this tool then you’re going to have to babysit it.

I think what you're describing is something that's built to perform agent based tasks. iterm-mcp isn't intended to be that. It's intended to be a bridge from something like Claude Desktop to iTerm. The REPL use case is a key thing to understand here.

What you're describing is great if you want to delegate "install python on my system" for example, but it doesn't support the REPL use case where you want to work with the REPL through something like Claude Desktop.

The other key use case iterm-mcp addresses is asking questions about what's sitting in the terminal right now. For example, you ran `brew install ffmpeg` and something didn't work: you can ask Claude using iterm-mcp.

> This tool seems like it locks you into iTerm2.

This tool is intended for use with iTerm2. It's not that it "locks you into iTerm2" - iterm-mcp is something that you would choose to use if you already use iTerm2.

> I wonder if there's really a need for separate write to terminal and read output functions? I was hoping that write command itself would execute and return the output of the command, saving back and forth latency.

I traded back and forth latency for lower token use. I didn't want to return gobs of output from `brew install ffmpeg` when the model really only needs to see the last line of output in order to know what to do next.

> The way I solved it is by setting a special PS1 prompt. So as soon as I get that prompt I know the task is done. I wonder if a similar thing can be done in your mcp?

What you suggested with changing the prompt is a good idea, but it breaks down in certain scenarios - particularly if the user is using a REPL. Part of my goal for this is to not have to modify the shell prompt or introduce visual indicators for the AI because I don't want the user to have to work around the AI. I want the AI to help as requested as if it's sitting at your keyboard. I don't want to introduce any friction or really any unwanted change to the user's workflow at all.

It's important to me that this work with REPL's and other interactive CLI utilities. If that weren't a design concern then I'd definitely explore the approach that you suggested.

This is an MCP server that integrates with Claude Desktop, LibreChat, and other Model Context Protocol compatible clients.

https://github.com/ferrislucas/iterm-mcp

Note: Independent project, not officially affiliated with iTerm2

## Features

*Efficient Token Use:* iterm-mcp gives the model the ability to inspect only the output that the model is interested in. The model typically only wants to see the last few lines of output even for long running commands.

*Natural Integration:* You share iTerm with the model. You can ask questions about what's on the screen, or delegate a task to the model and watch as it performs each step.

*Full Terminal Control and REPL support:* The model can start and interact with REPL's as well as send control characters like ctrl-c, ctrl-z, etc.

*Easy on the Dependencies:* iterm-mcp is built with minimal dependencies and is runnable via npx. It's designed to be easy to add to Claude Desktop and other MCP clients. It should just work.

## Real-World Example: Debugging Sidekiq Jobs

I needed to debug a Sidekiq job with complex arguments. The arguments were partially obfuscated in the logs. I asked Claude: "open rails console, show me arguments for the latest XYZ job". The model:

1. Launched Rails console 2. Retrieved job details 3. Displayed the arguments that I was looking for

## Architectural Journey

This project had a couple interesting constraints around command execution:

### 1. Token Efficiency Challenge

I wanted to constrain tokens as much as possible. I didn't want to send the entire output of a long running command to the model, but there's not a great way to know which parts of the output are important to what the model is doing. Sampling could be used here, but it's not well supported yet.

*Solution:* I arrived at a pull-based solution for this. The command from the model is sent to the terminal, and the model is made aware of how many lines of output were generated. The model can choose to retrieve as many lines of the buffer that it thinks are relevant.

### 2. Long-Running Process Support

I wanted to support long running processes. It turns out that when you run `brew install ffmpeg` - it takes a while, and it's not always clear when the job is done. In early proof of concepts, the model would assume the command completed successfully and begin sending additional commands to the terminal before the first command had finished.

*Solution:* iTerm provides a way to ask if the terminal is waiting for user input, but I found that it tended to show false positives in certain situations. For example, a long running command would result in iTerm reporting that the terminal was waiting for input when in fact the command was still running. I found that inspecting the processes associated with the terminal and waiting until the most interesting of those processes settles to a low resource usage is a fair indicator of long running commands being ready for input.

## Requirements

* iTerm2 must be running

* Node version 18 or greater

## Safety Considerations

* The user is responsible for using the tool safely.

* No built-in restrictions: iterm-mcp makes no attempt to evaluate the safety of commands that are executed.

* Models can behave in unexpected ways. The user is expected to monitor activity and abort when appropriate.

* For multi-step tasks, you may need to interrupt the model if it goes off track. Start with smaller, focused tasks until you're familiar with how the model behaves.

Comments URL: https://news.ycombinator.com/item?id=42880449

Points: 43

# Comments: 21

Together Gift It solves the problem just the way you’d think: with AI.

Just kidding. It solves the problem by keeping everything in one place. No more group texts! You can have private or shared gift lists, and there are some AI features like gift idea collaboration and product search. But the AI stuff is still a work in progress.

I’m grateful for any constructive feedback.

https://www.togethergiftit.com/

You can find out more here: https://github.com/ferrislucas/promptr

Together Gift It solves the problem the way you’d think: with AI. Just kidding. It solves the problem by keeping everything in one place. No more group texts. There are wish lists and everything you’d want around that type of thing. There is also AI.

https://www.togethergiftit.com/

Together Gift It solves the problem the way you’d think: with AI. Just kidding. It solves the problem by keeping everything in one place. No more group texts. There are wish lists and everything you’d want around that type of thing. There is also AI.

https://www.togethergiftit.com/

The system prompt that adds the Promptr CLI tool is here: https://github.com/ferrislucas/open-interpreter/pull/1/files...