Local · Claude Code + Codex

Your whole
codebase,
one team.

The Office coordinates Claude Code and Codex agents across every repository you own. One task, multiple floors, all reviewed by you before anything ships.

$ python3 office_server.py
Python 3.10+ Git No third-party deps Claude Code or Codex github.com/gagan1510/the-office ↗
THE OFFICE · http://127.0.0.1:8765
FLOOR 3
payments-service
Lead: Jordan
W1
W2
W3
W4
W5
FLOOR 2
platform-api
Lead: Sam
W1
W2
W3
W4
W5
FLOOR 1
auth-service
Lead: Alex
W1
W2
W3
W4
W5
▲ PAM · RECEPTION
Compares every request with all floor summaries and routes scoped assignments to the right team.
→ floor 1 → floor 2 → floor 3 + new floor

An office full of
people who know the code

Every project gets its own floor. Every floor has a persistent Lead who understands the codebase, and five Workers who can implement in parallel. Pam at reception handles the cross-project stuff.

▦
Floor
A durable workspace for one project: one repository, or a cupboard of many. State persists across restarts. Each floor runs its own agent (Claude Code or Codex).
◈
Lead
The Manager & Tech Lead on each floor. Analyzes incoming work, writes a plan, coordinates Workers, reviews their combined output, and owns the permanent project session.
⊞
Workers
Five per floor. Implement distinct workstreams in parallel, with serialization when paths overlap. Return to the pool when their assignment finishes.
☎
Pam
The platform's receptionist. Reads your request, compares it against every onboarded project, and routes scoped assignments to the floors that own the work.

What you can ask
The Office to do

Ask

Quick questions, grounded answers

Ask a floor a read-only question. The Lead answers using its onboarding context and repository. No implementation, no side effects. Can reference another floor for cross-project context.

"How does the session token refresh currently work in auth-service?"
Report

Deep investigation, no changes

Request a Report for a feature, migration, or architectural question. One Worker researches independently and returns: executive summary, recommended approach, ordered steps, risks, and the relevant files.

"How should we migrate our MongoDB collections to add tenant-scoped sharding?"
Specs

Phased implementation from a document

Paste or upload a Markdown specification. The platform parses ## Phase and ### item headings into a checklist stored in the repo under docs/specs/. Assign phases one at a time.

Upload a 6-phase migration spec. Run Phase 1. Review. Merge. Repeat.
Build from scratch

New apps, from requirements to first commit

Paste requirements or a document and The Office creates a new Git repository, commits a refined APP_BRIEF.md, and queues the initial build. The agent asks clarifying questions before starting.

"Build a Slack slash command that queries our internal wiki."
Workspace

Browse, edit, run, preview

Each floor has a full repository workspace: browse files, render Markdown docs, inspect branches and commits, run shell commands and detected dev servers, and see live previews.

Start the Vite dev server. The Office allocates a loopback port and shows the preview inline.

Implementation never pushes automatically. Review the working-tree diff, accept or reject individual hunks, and confirm branch creation explicitly. Every retained run has a checkpoint to roll back to.

From task to merged PR,
step by step

The Office checkpoints your repository before every run, coordinates workers safely, and requires explicit review before publishing anything.

Assign
Describe the task. Route via Reception or assign directly to a floor.
Plan
Lead analyzes, picks single or multi-worker plan, checkpoints the repo.
Work
Workers implement in parallel. Overlapping paths are serialized automatically.
Review
Inspect the diff. Accept or reject individual hunks. Edit the modified side directly.
Publish
Confirm the branch and destination. The Office stages, commits, pushes, and opens the PR.

The metaphor is clean.
The work is not.

A floor plan makes the system easy to understand. It does not make agent work deterministic. These are the boundaries I care about while building it.

Parallel work

Files are the collision boundary

Workers can run together when their paths do not overlap. If two plans touch the same file, The Office serializes them. That is slower, but easier to reason about than merging two plausible edits after the fact.

Context

Onboarding gets stale

The Lead keeps project context, but the repository remains the source of truth. Large refactors need a fresh scan. A remembered summary is useful context, not permission to ignore the current code.

Trust

A local repo can still be hostile

Dev scripts and repository instructions can execute code. I treat unknown repositories differently from code I own. Local-first keeps data on the machine, but it does not turn arbitrary code into trusted code.

Cost

Five workers are not the default

More agents add cost, logs, and coordination. The Lead should use one worker for one coherent change. Parallelism only helps when the work actually separates.

Up and running
in four steps

No third-party Python dependencies. Just Python 3.10+, Git, and at least one of Claude Code or Codex authenticated locally.

01

Start the server

From the project root. Startup output prints your data directory, detected CLIs, and the local address.

# from the office repo python3 office_server.py # custom port python3 office_server.py --port 9000
02

Open the browser

Navigate to the printed address. Keep the terminal open while agent runs are active. Stop with Ctrl+C only after runs have finished.

http://127.0.0.1:8765
03

Create a floor

Select + floor. Add a local repo path, a Git URL to clone, or a directory of repos (a cupboard). Onboarding is read-only and must succeed before tasks are enabled.

# paths The Office accepts ~/code/payments https://github.com/org/repo.git ~/code/services/ # cupboard
04

Assign a task

Open the floor and assign directly, or go to Reception for cross-project work. Pam routes; the Lead plans; Workers implement; you review before anything publishes.

VariableDefaultWhat it does
TASK_OFFICE_DATA_DIR~/.local/share/the-office/Where the SQLite database and backups are stored. Keep private; may contain repo paths, prompts, and session IDs.
TASK_OFFICE_CLAUDE_BINauto-detectedAbsolute path to the Claude CLI, when installed outside the standard search path.
TASK_OFFICE_CODEX_BINauto-detectedAbsolute path to the Codex CLI, same reason.
TASK_OFFICE_RUN_HISTORY200Number of agent runs to retain. Minimum 20. Each run stores up to 5,000 log entries.
TASK_OFFICE_HOOKS_DIRnoneDirectory containing on_run_finished, on_review_ready, or on_run_blocked executables for local notifications.
TASK_OFFICE_PREVIEW_PORT_MIN / MAX43100 – 43199Loopback port range for live dev server previews. Vite, Next.js, Flask, Django, and others are auto-detected.