A GitKraken alternative built around approval before Git writes.

The short answer

FluxGit and GitKraken are cross-platform desktop Git clients, and both now address coding-agent workflows. The useful difference is the control boundary. GitKraken documents MCP tools that can stage, commit, push, stash and manage worktrees. It also documents a separate Desktop experience for launching coding agents in worktrees, following their status and surfacing permission requests.

FluxGit makes a narrower architectural choice. Its public MCP exposes 23 read-only tools. Ten write contracts create proposals, and one contract cancels a pending proposal. The FluxGit desktop app shows operation-specific impact, risk and available recovery before a person approves execution. That boundary applies only to writes routed through FluxGit. A shell granted separately to Codex, Claude Code, Cursor or another host can still run Git outside FluxGit.

Three controls that sound similar but are not

Host permission decides whether an AI application may call a tool. Codex, Claude Code, Cursor and other hosts can ask before a call, apply an allowlist or grant a shell. That decision happens before a request reaches the integration.

MCP capability decides what the called tool can do. GitKraken's official MCP reference documents tools that directly stage or commit, switch branches, push, stash and create worktrees. Those tools can be enabled or disabled in the chosen agent or IDE. GitKraken Desktop separately documents agent sessions and permission-request events for supported coding-agent CLIs.

Application approval is the extra boundary FluxGit applies to its own write contracts. A FluxGit MCP call can inspect repository context immediately, but a supported write creates a proposal. The desktop app still requires a person to approve that specific operation before FluxGit runs it, even if the host already allowed the MCP call.

These controls can coexist. They also leave gaps if they are described too broadly. FluxGit cannot intercept a command executed through a separately authorized terminal, another MCP server or a different Git client. If every write must pass the proposal queue, remove those alternative write paths at the host or operating-system level.

FluxGit vs GitKraken

Agent sessions and parallel work

GitKraken has the broader documented session manager. Its Desktop guide names Claude Code, Codex CLI, Copilot CLI, Gemini CLI and OpenCode, launches those external CLIs in worktrees, displays agent activity and offers actions for reviewing or cleaning up the worktree after a session. That is a strong fit when the Git client is also the place where you start and observe several agents.

FluxGit connects to MCP hosts instead of trying to replace their complete session UI. Its focused pages explain setup and capability boundaries for Codex, Claude Code and Cursor. FluxGit can inspect linked worktrees, compare attempts and propose guarded operations, but this page does not present that as equivalent to every part of GitKraken Agent Sessions.

If parallel worktree orchestration is the main requirement, start with GitKraken's official session documentation. If an agent already runs in your preferred host and the missing control is approval inside the Git client before an MCP-routed write, test the FluxGit proposal path.

Recovery and everyday Git work

Both products go beyond an agent connector. GitKraken has a mature graph, branching, merge and rebase flows, conflict tooling and integrations. It also documents undo for the latest compatible action and immediate redo of a just-undone action. The supported-action list and limits matter; it is not accurate to describe any Git client's undo as universal.

FluxGit uses operation-specific recovery. Before a supported risky operation, the app explains the impact and whether a restore point can be captured. Restore points, reflog recovery and guarded resets cover different states, and the UI labels when recovery is unavailable. Read the restore-point limits and trust boundary rather than assuming every Git state can be restored.

Choose by the failure mode you need to manage. GitKraken offers a settled general-purpose Git experience with documented undo and redo. FluxGit places more emphasis on reviewing an agent-proposed operation before execution, recording the decision and preserving the recovery evidence that the specific operation supports. For a measured example of its context tools, see the reproducible Git context benchmark, including the published counterexample.

GitKraken's official undo and redo guide is the source for its supported actions and limits.

Choose FluxGit when approval before execution is the requirement

FluxGit is built for a workflow where reading and writing are different capabilities. An agent can inspect the repository without asking for approval on every read. When it wants FluxGit to perform a supported Git mutation, it creates a proposal instead of receiving a direct mutation endpoint.

The proposal carries the exact operation, the declared actor, risk information and the recovery path FluxGit can actually provide. A person reviews that proposal in the desktop app. Approval executes it through FluxGit's guarded path; rejection leaves it unexecuted. The decision and outcome enter the operation audit.

This is useful when your policy says a coding agent may gather Git context but may not independently commit, push, reset, discard, rebase or merge through the approved integration. Read the FluxGit MCP contract, the approval model and the operation audit.

Choose GitKraken when breadth and maturity matter more

GitKraken is the stronger fit when you want an established client with a broader documented ecosystem. Its MCP covers direct Git operations plus issue and pull-request workflows across several hosting and project systems. GitKraken Desktop also documents worktree-based agent sessions, support for five named coding-agent CLIs, live status and review actions after an agent finishes.

That can reduce tool switching for teams already using GitKraken, GitLens or its hosted integrations. It may also be the better choice if you need RPM, Snap or tarball options on Linux, formal support tiers, or years of conventional Git-client maturity.

See GitKraken's official coding-agent documentation, MCP tools reference, platform guide and current plans.

Limits you should decide with, not discover later

• FluxGit does not control a separately granted shell. If your coding-agent host can run arbitrary terminal commands, it can call Git outside FluxGit. Remove or constrain that permission if FluxGit is meant to be the write boundary.
• FluxGit is beta software. Version 0.5.1 is public for macOS, Windows and Linux. macOS builds are signed and notarized. The Windows installer currently triggers SmartScreen because it is not Authenticode-signed.
• FluxGit Linux coverage is narrow. The public package is a Debian package for x86_64. There is no ARM64 Linux build, RPM, Snap or AppImage today.
• FluxGit's paid checkout is not active. Public repositories are free. The one-time founder offer for private, self-hosted and local repositories is advertised, but purchase activation is still pending.
• GitKraken's product and plan details change. Use its linked official documentation and pricing page for a current buying decision.

How to evaluate FluxGit without disrupting your main repository

1. Use a disposable clone or a small public test repository. Do not begin with the only copy of work you care about.
2. Open it in FluxGit and inspect status, history and a diff before connecting an agent.
3. Connect one MCP host, keep its separate shell permissions visible, and ask it for repository context through the read-only tools.
4. Create a low-risk proposal such as a commit on a test branch. Confirm that the desktop app shows the operation and waits for your decision.
5. Reject one proposal, approve another and inspect the audit record. Then test one operation whose recovery path FluxGit labels explicitly.

There is no claimed automatic migration from GitKraken and no reason to uninstall it for this evaluation. Run both against disposable clones, compare the work each one makes clear, and keep the product that matches your actual control requirement.

Frequently asked questions

Is FluxGit a direct replacement for GitKraken?

It depends on the job. FluxGit focuses on proposal, approval, risk and recovery for Git writes routed through its MCP. GitKraken is a more established client with broader documented integrations and agent-session workflows.

Does FluxGit stop an AI agent from running Git in a shell?

No. FluxGit governs supported Git writes routed through its MCP. A shell or another tool granted separately by the host remains outside that boundary.

Does FluxGit support macOS, Windows and Linux?

Yes. FluxGit 0.5.1 has public builds for macOS Apple Silicon and Intel, Windows x64, and Linux x86_64 as a Debian package. The Windows installer is not Authenticode-signed yet.

Can an agent commit or push through FluxGit MCP without human approval?

No. FluxGit MCP write contracts create proposals. The desktop app requires human approval before FluxGit executes a supported write such as commit or push.

Is GitKraken better for agent worktrees?

GitKraken has the broader documented session manager for launching supported agent CLIs in worktrees, monitoring status and running parallel sessions. FluxGit focuses on approval inside the Git client before an MCP-proposed write executes.

Should I replace GitKraken with FluxGit?

GitKraken is a stronger fit for mature integrations, team plans and worktree-based agent management. FluxGit is worth testing when approval-before-write, operation-specific risk context and recovery are priorities.

Try the workflow on a public repository

FluxGit's free mode opens public repositories on supported hosts. Start there, connect an MCP host, inspect the repository with read-only tools and review a proposal before deciding whether the control model fits your work.