One tab for every repo, container and AI session on my machine

Developer Lorenzo Vicino built repo-control, an open-source dashboard that unifies Git repositories, Docker containers, and AI sessions into a single local tab. The tool scans local folders for repos, displays a queue of actionable items, and integrates with Claude Code, Codex, and Gemini CLI histories, all without cloud or telemetry. Vicino emphasizes security by ensuring the browser never sends file paths, only repository IDs.

My working day spans about ten Git repositories. Here is where their state actually lived: - which trees are dirty → forty terminal tabs - which branches are behind → a Git client, pointed at one repo at a time - which containers are up → docker ps - the AI conversation I had yesterday about the retry policy → somewhere under ~/.claude/projects , in a folder named after a path So I built repo-control . It scans that folder for Git repositories and serves a dashboard on 127.0.0.1 . No account, no cloud, no telemetry. Four things it puts in one tab: - What needs you — one queue, worst first: unhealthy containers, automations that failed, repositories to pull, commit or push. Click a row, land in that repo already scoped. - Every repo as a workspace — inline diffs, staging, commit, fetch/pull/push, branches with divergence and safe checkout, a terminal scoped to that folder that survives navigation, Compose state when there is a Compose file. - Your AI sessions — it reads the histories Claude Code, Codex and Gemini CLI already write to disk, keeps only the ones belonging to your workspace, and resumes any of them in a real terminal, in the right folder, with the right CLI. Nothing is copied anywhere. - Automations — drag Git, Docker and terminal nodes into a workflow: fetch everything, rebuild a stack, run one command across a selection. A dry run prints the exact commands first. One decision I will not budge on: the browser never sends a path. It sends a repository ID, the server resolves it against the root it scanned, and refuses anything outside. That is the whole difference between "a web page that runs shell commands on my machine" and something I leave open all day. What it is not: a team tool, and not where you do rebases or conflict resolution — that stays in your editor. It never calls the GitHub API. Everything it knows comes from git , docker and the files on disk. MIT, TypeScript end to end: github.com/LorenzoVicino/repo-control Now the part I actually want from you. I have built this against exactly one workflow: mine. Three questions: - Across your repos, what state do you lose track of most? - Is "one queue of what needs you" the right front page, or would you want something else there? - What would make you close the tab in the first minute? If you already have a system for keeping ten-plus repositories straight, I would rather hear that than a star.