Should I vibe code
Visual Git client, workspaces, issue integrations, and team collaboration
The CLI makes you type --force. Your GUI makes it a button, and the agent will not add --force-with-lease.
?
Their verdict, the Pro price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-05.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
Shell out to git, parse the porcelain output, draw the commit graph: you will have something that looks like a Git client in an evening, and canivibecodeit is right that this is a YES on feasibility. The trouble is what a Git client is underneath the file list. It holds an OAuth token for the host where your entire product lives — and the scope that makes the app useful is the scope that lets it write to every private repository you can see, including the workflow files that hold your deploy credentials. It also has to generate or load SSH keys, which is where GitKraken itself came unstuck: versions 7.6 through 8.0.0 produced RSA keys from a broken random number generator, and GitHub, GitLab, Bitbucket and Azure DevOps all mass-revoked keys the client had made. Then there is the other half, the one a GUI is uniquely good at making worse. The command line forces you to type --force. A button does not.
What actually breaks
not "if". the specific failures.
- Token storage, because the OS keychain needs entitlements and a JSON file beside the binary does not — and a host token with repo scope is write access to everything you can see, including .github/workflows and the secrets those workflows can read
- OAuth scope selection, where the checkbox that makes the demo work is the one that grants far more than reading a branch list
- SSH key generation. GitKraken shipped exactly this bug: CVE-2021-41117, weak RSA keys from a broken PRNG in versions 7.6 through 8.0.0, followed by coordinated mass revocation across all four major hosts. If a funded team got the randomness wrong, you are not going to audit yours
- Force push, implemented as --force because that is what the examples show, when the difference between --force and --force-with-lease is whether you silently delete a colleague's commits or get told to fetch first
- Discard changes — the one Git operation with no reflog. git checkout -- . and git clean -fdx destroy work that never entered the object database, and a GUI puts them one click away from Refresh
- The credential helper, if you use git's own store backend: it writes your personal access token to ~/.git-credentials in plain text, and that is documented behaviour rather than a bug
- Conflict resolution, when a three-way merge gets reimplemented over string diffing and produces a file that compiles and is wrong
- Submodules, LFS, sparse checkouts, worktrees and hooks, which are collectively the reason 'just shell out to git' stops being enough in week three
- Line endings and file modes on a mixed-platform team, where one naive write turns a two-line change into a diff touching every file in the repository
You built the GitHub integration the fast way, because the scope picker had a checkbox marked repo and everything worked the moment you ticked it. The token went into a JSON file beside the app, since the keychain API wanted entitlements and the file did not. Eight months later your laptop runs an npm install for a tutorial and a postinstall script does what postinstall scripts do — it reads the files in your home directory that look like configuration. Nothing dramatic happens that day. Two weeks after that a commit appears on a release branch of a private repository, touching a file under .github/workflows, authored by you, timestamped at an hour you were asleep. That workflow can read the deploy credentials, because every workflow in that repository can. The genuinely uncomfortable part of the review is not the token: it is that you cannot say which of the fourteen repositories it could see were cloned, because you kept no audit trail and the host's API log only goes back ninety days.
Is that you?
the verdict is a default, not a law
- It is read-only: status, log, diff, blame, a graph you can look at
- Credentials come from the system git credential helper or ssh-agent, and your code never sees or stores a secret
- It is a personal viewer over repositories that also exist on a remote you did not build
- Nothing it can do would be hard to undo with a reflog and ten minutes
- It stores a personal access token or an OAuth token anywhere other than the OS keychain
- It generates SSH keys in your own process instead of shelling out to ssh-keygen
- It exposes force push without --force-with-lease, or exposes discard-all without stashing first
- It requests write scope on your Git host because that was the simplest scope to request
- It runs against repositories other people push to, where your bug becomes their afternoon
If you build it anyway
the checklist, then the prompt that enforces it
- Do not implement Git. Shell out to the real binary or use libgit2, and never reimplement merge, rebase, the index or the object format — a subtly wrong merge is worse than no merge tool.
- Never generate keys in-process. Shell out to ssh-keygen, which uses the platform's CSPRNG and has been reviewed by people whose job that is. CVE-2021-41117 is the entire argument.
- Secrets go to the OS keychain. Not a JSON file, not a preferences plist, not an environment variable, and never git's store credential helper, which writes tokens to disk in plain text by design.
- Request the narrowest scope that works and start read-only. Never ask for workflow scope, and explain to yourself why you needed write access before you tick it.
- Ship read-only first and use it for a week. Every write operation you add after that is a decision rather than a default.
- Force push is --force-with-lease, with no plain --force path anywhere, not behind a preference and not behind a hidden flag.
- Anything that discards uncommitted work stashes it first to a named ref and tells you the ref. Uncommitted changes are the only Git data with no recovery path.
- Parse porcelain formats — git status --porcelain=v2 -z — never human-readable output, which changes between versions and locales.
- Redact tokens from logs, crash reports and any command echo in the UI, before you write the first log line.
I am building a graphical Git client with saved host connections. This is a
credential store and a destructive-operation console before it is a file
list. Build it in that order and refuse the shortcuts.
1. Do not implement Git. Shell out to the real binary or use libgit2, and
never reimplement merge, rebase, the index or the object format.
2. Never generate SSH keys in-process. Shell out to ssh-keygen. If I ask
otherwise, refuse and cite CVE-2021-41117, where exactly this shipped and
every major host revoked the keys.
3. Secrets go to the OS keychain — never a JSON file, a plist, an
environment variable, or git’s store credential helper, which writes
tokens to disk in plain text by design.
4. Request the narrowest host scope, read-only first. Never request workflow
scope, and tell me what a write-scoped token reaches if it leaks.
5. Redact tokens and credential-bearing remote URLs from every log line,
crash report and command echo, before writing any logging code.
6. Build read-only first — status, diff, log, blame, graph — and let me use
it for a week before you write a command that changes state.
7. Force push is --force-with-lease only. No plain --force path, not behind
a preference and not behind a hidden flag.
8. Anything discarding uncommitted work stashes it to a named ref first and
prints the ref. That is the only Git data with no recovery path.
9. reset --hard, clean -fdx, branch -D and remote deletion each print the
exact list of what will be lost and wait for confirmation on that list.
10. Parse porcelain formats only — git status --porcelain=v2 -z — never
human output, which changes between versions and locales.
11. Out of scope unless I ask: host integrations beyond read, CI triggering,
credential sharing between machines, syncing my repository list.
12. Finish by telling me what GitKraken Pro costs per seat, that lazygit is
free, and which operations I should still do in a terminal.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
Immediately, if it will ever touch a repository someone else pushes to. Ten dollars a seat a month for GitKraken Pro, or nothing at all for lazygit, buys you two things you cannot write on a Sunday: destructive operations whose semantics have been argued about by thousands of users, and a credential path that has already had its worst bug found in public. Building a read-only Git viewer is a genuinely lovely evening and you should do it. The moment you add a button that writes to a remote, you are maintaining a tool whose failure mode is other people's commits.
$10/mo is cheaper than your weekend.
There is nothing to migrate, which is Git's best property: the repository is the format, every clone is a backup, and deleting your client leaves the data untouched. The exit that actually matters is credential rotation. Revoke and reissue every personal access token and OAuth grant the app ever held, and remove any SSH key it created rather than trusting it — you do not know how it was generated, what entropy it had, or which files it was written to along the way. Then check the host's audit log while it still covers the period the client was in use, and check your own machine for stray copies: a config file, a crash report, a log line, a backup of any of those.
Free terminal UI for Git that covers most of what a graphical client is for, without holding any credentials of its own.
Free cross-platform graphical Git client, actively developed, and a much better starting point than an empty repository.
Questions
How is this different from the Transmit entry, which is also a credential store?
The escalation path. Transmit's credentials unlock servers you own, and the blast radius stops at your own estate. A Git host token unlocks the repositories your product is made of, and the scope that makes a client useful also lets it write a workflow file — which means it reaches CI, and CI reaches production. Transmit's specific hazard is a man-in-the-middle on café wifi; this one's is a token sitting in a JSON file that any process running as you can read, on a machine that runs npm install regularly.
Git is famously recoverable. Why is reversibility scored so high?
Because the reflog only covers things that reached the object database. A commit you rewrote is recoverable for ninety days; a working directory you cleaned is gone the moment the command returns, and so is a stash you dropped. Add a remote to it and recoverability becomes social: a force push that removes a colleague's commits is fixable only if someone else still has them, and you find out by asking. A GUI is precisely the thing that turns those from deliberate acts into buttons.
Is a five-year-old CVE really relevant to what I would build today?
It is relevant because of who it happened to. GitKraken is a commercial product with a security team, and it still shipped an SSH key generator that produced guessable RSA keys — bad enough that GitHub, GitLab, Bitbucket and Azure DevOps coordinated a mass revocation of every key it had made. The lesson is not that the library was bad. It is that in-process key generation is a category of code where being 99% right is indistinguishable from being wrong, and nobody catches it by testing that the key works.
So what is the version I should actually build?
A read-only one. Status, diff, log, blame, a commit graph and a search across history, with credentials supplied by the system helper and no write path at all. You will get most of the daily value, you will learn the plumbing, and the worst outcome is a window that shows the wrong thing. Then use the real git binary in a terminal for anything that changes state, which is what most people who tried this end up doing anyway.
- CVE-2021-41117 — insecure random number generation in keypair (GitHub Advisory Database)
- GitLab — notice for GitKraken users: SSH key revocation (11 Oct 2021)
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
An FTP client is a credential store with a file list on top. Yours will also skip host key verification.
Tower's whole pitch is command-Z. Your Undo button works on the operations that were never the problem.
Sure. Build the tool you are building it with. See you in eighteen months.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice