Friday Agent Workbench
Coordinate local coding agents to split work, communicate, and hand off tasks when a tool reaches its usage limit.
- Source repo
- splashxmoon/friday
- Stars
- ★ 36
- Last updated
- 1d ago
- License
- MIT
- Primary language
- TypeScript
- FA score
- 68/100 · Some gaps
At a glance
- How it runs
- Works with
- Universal · cross-platformCodex · Claude CodeOpenAI API · Claude API (Partial support)
- Cost
- Free tier plus a paid hosted plan
- Setup effort
- Low · running in minutes
- You'll need
- Typical use
- An independent developer wants Claude Code and Codex to handle a feature and its tests in parallel worktrees.
- Not a fit if
- Users unwilling to install and sign in to a supported coding tool
- Teams that need multiple people to share one session
- Source review
- 68/100 · Some gaps
What does this agent do, and when should you use it?
Friday is a desktop app for macOS, Windows, and Linux, and it can also launch a local web interface through Node.js. It drives coding tools already installed and signed in on your computer, including Claude Code, Codex, Cursor, Gemini CLI, and GitHub Copilot. Agents can divide work on a shared task board, message one another, and work in separate Git worktrees; Friday runs tests and can assign another agent to review changes when tests do not settle the result. If an agent reaches a usage limit, its task and work record can be handed to another suitable agent. You review the resulting change set before using the built-in Git tools to commit or open a pull request. Friday runs locally and does not require an account.
Launch Friday locally, choose a repository or folder, and start a session; Friday detects installed and signed-in coding tools. Add one or more agents to work on files in separate Git worktrees, exchange session messages, and split or claim tasks on a shared board. When tasks finish, Friday runs tests and can have another agent review changes that tests do not settle. If an agent runs out of usage, Friday hands the task and its work record to a suitable agent. You can inspect the change set, leave line or range feedback, and use the built-in Git panel to stage, commit, push, or open a pull request. Automations can also run on a schedule, webhook, or session event.
- An independent developer wants Claude Code and Codex to handle a feature and its tests in parallel worktrees.
- A developer with subscriptions to several coding tools wants one local place to assign work and hand tasks over when usage runs out.
- A maintenance team wants recurring coding jobs triggered by a schedule or webhook, with each run reviewed through its session or pull request.
- A developer who needs to inspect agent changes before committing wants change sets, line-level feedback, and built-in Git actions.
- A user wants an external MCP client to start local Friday sessions, read agent status, and answer questions or permission requests.
How do you install or deploy this agent?
Download the desktop installer for your operating system. The terminal option requires Node.js 22 or newer and Git, and you must first install and sign in to at least one supported coding tool. You can also clone the repository and start it from source.
How do you use this agent?
Sign in to a coding tool, launch Friday, and select a repository. Start a session with a task, then add other agents when you want to split the work. Review the resulting change set and decide whether to keep it, commit it, or open a pull request.
What are this agent's strengths and limitations?
- Coordinates installed tools including Claude Code, Codex, Cursor, Gemini CLI, and Copilot, with support for any ACP agent.
- Separate Git worktrees, a shared task board, and agent messaging support parallel work without agents overwriting one another's files.
- Can hand off tasks with their work records when usage runs out, while keeping changes reviewable before shipping.
- Offers desktop and local web app delivery on macOS, Windows, and Linux.
- Requires at least one supported coding tool installed and signed in; Friday drives those tools rather than supplying a default model.
- Agents remain subject to their own plans, usage limits, and sign-in status; handoff depends on another usable agent being available.
- Local automations and Crew work require Friday to keep running; the desktop app can keep the computer awake while work is in hand.
- The README describes Friday Team as the hosted option for shared sessions with multiple people; that team workflow is not the local app's offering.
How does this agent compare with similar options?
Friday brings existing coding CLIs and agents into one workspace for task splitting and handoffs. Compared with using those tools one at a time, it adds a shared task board, agent messaging, usage-limit handoffs, and a change review flow. It is not a framework that requires you to write custom agents.
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| Friday Agent Workbench This agent | 68 · Some gaps | Desktop appFreemium | ★ 36 | 1d ago | TypeScript | Codex · Claude Code |
| Happier | 82 · Good | Desktop appFree + model costs | ★ 2.1k | today | TypeScript | Codex · Claude Code |
| Fusion Software Factory | 71 · Some gaps | CLIFree + model costs | ★ 1.3k | 4d ago | TypeScript | Codex · OpenAI API · Claude API |
| Ateam Agent Workbench | 70 · Some gaps | Desktop appFree + model costs | ★ 15 | today | TypeScript | Codex · Claude Code |
How does FollowAgents rate this agent?
Why each dimension lost points
Trust: README Privacy and SECURITY.md clearly state 127.0.0.1-only binding, cross-site request rejection, and local-token MCP access, giving strong data_flow_transparency (3). least_privilege scores 2: per-agent Read only/Ask/Full access is claimed and ACP tests show no fs/terminal capabilities granted, but the permission model source is absent so defaults cannot be verified. user_confirmation scores 2: approvals and Plan/Ask modes exist, yet Auto mode auto-approves commands (test shows rm -rf dist auto-allowed), so default behavior needs user judgment. sensitive_data_handling scores 2: keys stay local and telemetry excludes code, but telemetry is on by default (sent only after user answers) and no encryption/key-storage detail is given. dependency_security scores 1: many dependencies with caret ranges, allowScripts permits several install scripts, and no lockfile audit or vulnerability scanning evidence. external_effects scores 2: Git commit/push/PR, auto-update, and webhook automations are external effects but require user action or explicit config. rollback scores 2: rewind, worktree isolation, and review-before-commit exist, but no rollback for already-pushed changes. source_attribution scores 1: LICENSE names Arun Dass, publisher is unverified, and the README does not explain the relationship to the tryfridaywork.com commercial entity.
Reliability: self_consistency scores 2, README claims broadly match tests (ACP adapter, activity line, worktree dedup), but the README is truncated, the FAQ is incomplete, and some claims (multi-tool usage reading) lack source support. dependency_availability scores 1: a large dependency set including Electron and node-pty native modules, only Node>=22 declared, no lockfile or version pinning evidence, and floating ranges raise unavailability risk. failure_messages scores 3: test/activity-line.test.ts shows raw errors converted to human-readable lines (e.g. 'Stopped: their tool failed to start'), and ACP tests verify not-signed-in and lost-session messages, so failure messaging is well handled.
Adaptability: audience_and_scenarios scores 3, covering Code/Work/Crew scenarios, many tools, and multiple platforms with clear audience positioning. capability_boundaries scores 2: supported tools and generic ACP are described, but unsupported tools and model capability limits are thinly covered. trigger_precision scores 2: automations support schedule, webhook, and event triggers with a daily cap, but precise trigger semantics lack detail. environment_fit scores 2: macOS/Windows/Linux and Node 22 are declared, but the Windows installer is unsigned and cross-platform native build risks are not fully addressed.
Convention: information_architecture scores 3, with a well-organized README table of contents, sections, tables, and screenshots. install_notes scores 3: per-platform downloads, Homebrew, npx, source install, and env vars are documented with a sign-in prerequisite. naming_stability scores 2: package name friday-work, repo name friday, and product name Friday diverge. examples_and_faq scores 2: examples and an FAQ exist but the FAQ is truncated. known_limitations scores 2: unsigned Windows installer and keep-awake needs are noted, but limitations are not systematically listed. license scores 3: full MIT license consistent with package.json. versioning_changelog scores 1: version 0.2.7 and a release flow exist but no CHANGELOG file. maintenance_responsibility scores 1: publisher is unverified, with only a security email and CONTRIBUTING mention, leaving the responsible maintainer unclear.
Effectiveness: output_usability scores 2, producing reviewable change sets, task boards, and document outputs, though output quality lacks quantified evidence. marginal_value scores 2: multi-agent coordination and limit handoff are differentiating, but competition is heavy and incremental value needs real validation. cost_benefit scores 2: local and free, reusing existing subscriptions, but depends on multiple tool logins and local resources.
Verifiability: claim_traceability scores 2, some claims trace to source (src/usage.ts, test files) but most feature claims lack source references. cross_source_corroboration scores 2: README, tests, CI, and SECURITY partially corroborate each other (ACP permissions, error handling), but core collaboration mechanics lack cross-evidence. fact_inference_separation scores 2: docs distinguish facts from marketing, but assertions like 'there isn't a catch' are subjective and not flagged as inference.
- Publisher identity is unverified; LICENSE names Arun Dass and the relationship to the tryfridaywork.com commercial entity is unexplained, so verify provenance before installing.
- Telemetry is on by default (asked at first welcome); it can be disabled but requires opt-out.
- Auto mode auto-approves commands (test shows rm -rf dist auto-allowed); confirm default permission settings before use.
- A large dependency set with floating versions, native modules, and install scripts; no lockfile audit or vulnerability scanning evidence.
- The Windows installer is unsigned, requiring manual bypass of warnings on first run.
- README and FAQ are truncated and some feature claims lack source support; treat them cautiously.
Recent releases
Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.
-
v0.2.10 Friday v0.2.10
Release notes excerpt
What's new - Rules that stick. Tell an agent "never touch the migrations" once and Friday offers it as a rule. Every agent's work is then checked against it: a command to run, lines that must never appear, or folders to leave alone. Edit them in Settings › Memory. - Was it already broken? When a test fails after an agent's turn, Friday runs it again on the code from before the agent started. A failure that was already there is marked as such, so nobody chases it, and the agent is told so too. …View on GitHub ↗ -
v0.2.9 Friday v0.2.9
Release notes excerpt
What's new - Changes, rebuilt. The Diff panel is now Changes. Each agent that changed something has a chip, with its small ring while it works. In a Crew, Everyone shows all the changes together, by folder, each file once with the names of whoever changed it. Checks and a commit box sit at the panel's foot (Commit & open PR, ⌘↵). A teammate working in a folder that holds repositories shows their real changes, and leftovers like .DS_Store or Claude Code's lock file never show. …View on GitHub ↗ -
v0.2.8 Friday v0.2.8
Release notes excerpt
What's new - Qwen Code. Friday finds Qwen Code on your computer and runs it like the other coding tools, over ACP, with Manual, Auto and Plan kept to what they say. Contributed by @PrathamShenoy14 (#10), our first outside pull request. Thank you! - Workflows you can steer step by step. A step's "Who does it" now lists the coding tools on your computer, each account on its own line (Claude Code · Work), and picking one makes it a teammate in the room right away. A check that fails can send the fixes to someone else, another teammate, tool or account, and then checks again. You can d …View on GitHub ↗