Known issues in the current release
Limitations worth knowing before you hit them.
Written By Dustin
Last updated 16 minutes ago
Maintained deliberately, so you find these here rather than by running into them.
Locking
A Forge arbitrates lock grants, but no push or land path consults a lock store or checks the holder. A lock coordinates; it does not hard-block another identity’s write. The one gate that does refuse, TVO-LOCK-002, is holder-agnostic: it refuses a land when an exclusive-lockable path diverged on both sides, whether or not anyone holds a lock.
Git interoperability
- Force push is not implemented. Over the Git bridge, a non-fast-forward publish is refused (
TVO-MIG-006) and the bridge never force-pushes. Pushing into a Forge with a Git client, a non-fast-forward update is refused when the token lacks force authority on the lane (TVO-GHC-061); the force allow-path itself is still open work. - Signed-commit repositories cannot accept a Git push at all. The bridge imports every pushed commit unsigned under the serving key, so the policy can never be satisfied over Git (
TVO-GHC-062). Use the native client. - Consumer OIDC sign-in is the one remaining gate on the GitHub-compatible OAuth token endpoint: authorization-code issuance after human sign-in returns an honest
501. The rest of the authorization-code and PKCE path is built. - The
blake3-to-git-oidcache is not persisted, so repeated bridge operations redo translation work. - GitHub issues, labels, milestones, and GraphQL are deliberately unsupported by the compatibility facade — those routes answer
501rather than fake a surface. That is a non-goal, not a gap.
Pushing to a review-required lane does route into a proposal. A direct Git push to such a lane is refused fail-closed with TVO-GHC-063, and pushing to refs/for/<lane> imports the commits and opens a Proposal targeting that lane without advancing the real ref.
Not yet available
- Hosted TOVIO Cloud — no accounts, no billing, no hosted repositories. Run your own Forge.
- Published, signed installers. The packaging, signing, and notarization workflows exist for all six OS/architecture targets, but production signing credentials, clean-runner evidence, and publication are open work — so in practice installing today means building from source.
Evidence gaps rather than bugs
These are things that are built but not yet independently proven. They are worth knowing before you bet something important on them.
- No independent security audit of the cryptography and permission enforcement.
- No scale evidence at the declared ceilings. Contention is verified at a modest writer count; the large agent-fleet, relay-session, and noisy-neighbour dimensions are open.
- Platform floors are declared, not certified. Every target has a stated minimum OS, keychain backend, and package set, and every one of them currently reads
certified: false— a certification run at the floor has not happened, because a run above it certifies only that host. - JetBrains and Desktop have less acceptance evidence than the CLI and VS Code, and neither is published to its marketplace yet.
- Enterprise identity federation (LDAP, SAML, OIDC, SCIM) exists in-tree, but live-provider and credential-rotation evidence is open.
Authoritative source
The dated current-state document on the documentation site. Where it and this article disagree, it is right — and telling us this article has drifted is a useful report in itself.