Friday Coordinates Coding Agents With a Local Harness | Zeniteq
Loading
Loading article
Friday Coordinates Coding Agents With a Local Harness
The MIT-licensed tool brings Claude Code, Codex, Cursor and Gemini CLI into a shared local workflow, with task boards, separate repository copies and usage-limit handoffs.
Friday is an open-source coding-agent harness that coordinates multiple AI assistants within a single local workflow. The tool allows developers to manage a team of agents—including Claude Code, Codex, Cursor, and Gemini CLI—by providing a shared task board, agent-to-agent messaging, and isolated repository copies to prevent editing collisions.
The MIT-licensed software runs locally without a required account or hosted control service. It supports usage-limit handoffs, where tasks transfer between agents when one provider’s allowance is exhausted, though these capabilities rely on the underlying tools' configurations.
Friday is an open-source coding-agent harness designed to coordinate several assistants on one computer. Its GitHub documentation lists support for Anthropic’s Claude Code, OpenAI’s Codex, Cursor, Google’s Gemini CLI, GitHub Copilot and other tools. Agents can divide a job, exchange messages and continue one another’s work when a provider’s usage allowance runs out.
The project’s central distinction is coordination. Opening several coding assistants gives a developer multiple places to send prompts. Friday adds a shared task board, agent-to-agent messaging, optional isolated repository copies and a review workflow around those assistants.
The local version is free and MIT-licensed, and the project says it requires no Friday account or hosted control service. One qualification: these are documented capabilities, not independently measured results. This article analyzes the project’s published workflow; compatibility, handoff reliability and privacy claims have not been independently verified.
How Friday Turns Separate Assistants Into a Team
Friday works with coding tools already installed and signed in on the developer’s machine. Its README lists Claude Code, Codex, Cursor, GitHub Copilot, OpenCode, Gemini CLI, Devin, Junie, Kiro, Factory Droid, Grok Build, Cline, Kilo and Amp, alongside support for ACP-compatible agents.
A session can begin with one agent breaking a larger request into tasks. Other agents then pick up portions of the work. Friday’s documentation describes a shared board where progress and dependencies remain visible, plus direct messages between agents.
That messaging has a practical purpose. An assistant changing a function name can tell another assistant before it writes code against the old interface. An agent facing an ambiguous requirement can ask a question and receive an answer without making the developer relay it manually. Friday says those messages appear in a live feed.
The documented completion process also includes running tests and having another agent review finished work before a task counts as done. Separately, the developer gets a change set to inspect before keeping it. Friday supports comments on individual lines or ranges, which can be sent back to the agent for revision. These features are described in the official README.
I’d treat the task board and review gates as more important than the number of supported assistants. A larger agent roster is useful only if the work has clear boundaries and someone checks the combined result. Adding another assistant to a poorly specified task can create another interpretation of the same ambiguity.
Work with Zeniteq
Promote your app with us
Reach readers exploring AI tools and workflows. Discover sponsorship and advertising options for your app.
An illustrative division might assign an API change to one agent, interface updates to another and tests to a third. That is a plausible use of Friday’s documented workflow, not a tested example or a promise that every repository can be split cleanly.
Separate Repository Copies Reduce Editing Collisions
Friday lets an agent added to a session work in its own copy of the repository. That gives parallel agents separate working files, addressing a basic problem with having several assistants edit the same checkout.
Two agents operating in one directory can interfere before Git ever enters the picture. One may read a file while another is rewriting it, or run tests against changes it did not make. Separate repository copies reduce that immediate interference.
They do not eliminate integration work.
Workflow
What Happens During Editing
What Still Needs Attention
Several agents share one checkout
Agents can encounter one another’s in-progress edits
File collisions, changing test conditions and unclear ownership
Agents use separate repository copies
Each agent has an isolated working copy
Combining changes and checking that they work together
Tasks have clear boundaries and messaging
Agents can communicate interface changes and dependencies
Validating that their shared assumptions are correct
The distinction between isolation and integration matters. Two changes can be valid in their separate copies yet disagree about a function signature, configuration format or database assumption. Even changes that combine without a textual conflict can produce incorrect behavior together.
My reading is that Friday’s repository isolation and messaging solve different layers of the problem. Isolation protects the editing process; messages help agents coordinate meaning. Tests and developer review still have to assess the integrated result.
The repository documentation also says sessions can target an existing branch or start a new one from another branch. Friday says it will not switch a folder with uncommitted work out from under the developer. Its Git interface supports staging by file or hunk, committing, pulling, pushing and opening pull requests, including stacked pull requests.
Those controls make the final review consequential. Small, understandable changes are easier to inspect than a large combined diff, regardless of how many agents produced them.
Usage-Limit Handoffs Preserve Work, Not Unlimited Capacity
Friday’s usage-limit feature targets developers who already move between AI products when one subscription reaches its allowance.
According to the README, Friday displays each tool’s remaining usage. Developers can choose an assistant for a task or let an Auto option choose based on the job and available usage. If one assistant runs out during a task, Friday says the task moves to another agent with the work completed so far.
The documented sequence is:
An agent begins a task using its existing account or subscription.
Friday tracks the tool’s remaining usage.
When the limit is reached, Friday selects another agent positioned to continue.
The successor receives the task and accumulated work instead of starting from an empty assignment.
The practical benefit is continuity across tools. It is not extra capacity from the provider that imposed the limit. Another eligible assistant still needs to be available, authenticated and able to continue under its own plan.
The README’s promise to carry work forward also should not be read as a guarantee that different assistants share identical internal state. The published description does not establish exactly which conversation details, intermediate reasoning or tool-specific session state survive every cross-tool handoff.
I’d plan a handoff around explicit artifacts: the task description, changed files, test results, unresolved questions and decisions already made. Those give the next assistant something inspectable to work from. A task that depends on assumptions buried in a long conversation is harder to transfer reliably.
There is also an economic limit to the feature. Friday’s documentation provides no comparative benchmark or cost study showing that multi-agent execution is cheaper or faster than one assistant. Parallel work and additional review can consume more usage. Its documented advantage is coordinating available tools and allowances, not proving a reduction in total cost.
Installing Friday Without a Hosted Control Service
Friday offers desktop downloads for Apple silicon Macs, Intel Macs, Windows and Linux. The terminal route requires Node.js 22 or newer and Git.
The README gives this command:
npx github:splashxmoon/friday
That command starts Friday from the GitHub project through npx; it is the documented installation route, not a command executed for this article.
By default, Friday opens a browser interface at http://127.0.0.1:4321. Its session and settings directory defaults to ~/.friday. The PORT and FRIDAY_HOME settings change those defaults, and --no-open starts it without opening the browser.
At least one supported coding tool must already be installed and signed in. The README lists provider-specific authentication steps, such as claude auth login for Claude Code and codex login for Codex. For Gemini CLI, it tells developers to run gemini once and sign in. Friday says it detects installed tools and their sign-in status, with setup options for signing in additional tools.
Two packaging details deserve attention. The project says its Mac application is signed and notarized by Apple. Its Windows installer is described as unsigned, which triggers a Windows warning. On a managed work machine, I’d check the organization’s software-installation policy before proceeding with an unsigned installer.
The installation documentation explains that the desktop app contains the same local server as the browser version. “No hosted server” therefore does not mean there is no server process: Friday runs one on the local computer, bound to the loopback address.
Local Coordination Is Not the Same as Offline AI
Friday’s README describes the local product as having no Friday account, no company-hosted server requirement and no telemetry. Its privacy pitch includes the statement:
“nothing comes back to us.”
That is a claim about Friday’s own service boundary. It does not make every connected coding assistant offline.
Claude Code, Codex, Gemini CLI and other connected tools retain their own authentication, service behavior and data-handling terms. Running their coordinator locally does not, by itself, change where those assistants send model requests. Developers handling sensitive repositories still need to examine each selected tool’s configuration and applicable policies.
Friday also documents an optional built-in agent, Friday Code. Developers can configure it with their own model access, including API keys for providers such as OpenAI, Anthropic and Google, or a locally running model through Ollama or LM Studio.
That creates a separate configuration choice. A local model can change the inference path, but the whole session’s behavior depends on which agents and integrations are enabled. “Local harness” is a precise description of the coordinator’s placement, not a blanket privacy guarantee for every workflow it launches.
The MIT license makes the local software available under a permissive open-source license, allowing modification and redistribution subject to its terms. It does not supply model access or remove connected providers’ subscription conditions.
The project’s commercial offering is Friday Team, a hosted version described as supporting several people in one session, shared steering of an agent and collaborative review. That is distinct from the local version’s promise of coordinating multiple agents for a developer without requiring Friday’s hosted control service.
For an initial evaluation, I’d choose a small, testable change with two clearly separated tasks. That would make it easier to assess the capabilities that matter: whether task status stays understandable, whether agents communicate consequential changes, whether a handoff preserves enough context and whether the final combined diff remains reviewable.
Frequently Asked Questions
3 questions
1
Does Friday Replace Claude Code or Codex?
No. Friday coordinates installed coding tools and uses their existing sign-ins and plans. It also offers an optional built-in agent that can use a configured model.
2
Can Friday Run Entirely Offline?
The coordinator runs locally, but connected assistants may use remote services. Friday documents local-model support through Ollama or LM Studio; the overall setup determines its network requirements.
3
Do Separate Repository Copies Prevent Every Conflict?
They reduce interference while agents edit. Their changes still need to be combined and tested, because isolated work can contain conflicting assumptions even without overlapping file edits.
