Flathub Draws a Hard Line on AI: No Vibe-Coded Apps Allowed, Period

On May 29, 2026, Flathub maintainer Bart Piotrowski rewrote the Linux app store's generative AI policy to ban all applications containing AI-generated or AI-assisted code, documentation, or content. The move, prompted by a surge in low-effort submissions and hostile interactions with "vibe-coders," replaces previous nuanced language with a blanket prohibition that has sparked intense debate across developer forums.

Burned-Out Flathub Maintainers Just Banned AI Code From the Linux App Store and Nobody Can Agree If It Was the Right Call On May 29, 2026, a single GitHub commit changed how thousands of Linux app developers have to think about publishing software. Flathub, the dominant Flatpak app repository for Linux, quietly rewrote its generative AI policy to make one thing clear: apps built with AI assistance are not welcome, full stop. The commit, authored by Flathub maintainer Bart Piotrowski barthalion , stripped out the previous nuanced language and replaced it with something far less forgiving. And the fallout across Reddit, Mastodon, and developer forums has been loud ever since. What the Old Policy Said vs. What It Says Now The previous policy was already restrictive, but it had wiggle room. It prohibited submissions “where most of the code is written by or using AI without any meaningful human input, review, justification or moderation.” It also blocked “low-quality AI-generated or AI-assisted code.” The new policy cuts all of that nuance and replaces it with one line: “Applications containing AI-generated or AI-assisted code, documentation, or other content are not allowed.” That covers the app itself, the Flatpak manifest, metadata, build scripts, patches, and the pull request used to submit it. Automated Copilot reviews on GitHub must also be disabled before submitting, with a specific link provided to turn off the feature. The policy applies to BaseApps, extensions, and any other artifacts built through flatpak-builder. In other words, if AI touched it anywhere in the pipeline, Flathub does not want it. Why the Maintainer Hit the Nuclear Option Piotrowski did not hide the reason. In a Mastodon post accompanying the commit, he explained it plainly: “The number of unpleasant interactions I’ve had with entitled submitters acting as if they were bestowing their brilliant software upon us idiots who are rejecting it went through the roof in the last month. I’m tired.” He acknowledged having reservations about such a broad ban, noting that he personally believes LLMs are “inevitable” and can be a useful tool. But the volume of low-effort submissions combined with the hostility of vibe-coders when their apps got rejected apparently pushed the team past its limit. Piotrowski also noted that the previous, gentler policy did not actually reduce the workload. When maintainers tried to reject apps based on “insufficient development history” or “project health,” submitters just disputed the rules and created more work. A harder, vaguer ban gives reviewers cover to reject slop without getting drawn into arguments. The “Mature Projects” Exception — and Why It’s Already Controversial The policy does include one escape hatch: “Exceptions may be granted for mature, well-maintained projects.” This is where a lot of the community debate is concentrated. Critics point out that “mature” and “well-maintained” are not defined anywhere. Piotrowski clarified in follow-up replies that projects with “community engagement, release cadence, CI, and that seem to have been more than pure slop produced in 3 weeks” would likely qualify. But that is still a judgment call made by a small team of human reviewers with no published rubric. No minimum age requirement. There is no stated threshold for how old a project must be. No contributor count requirement. The number of active contributors is not specified. No appeal process described. The policy says exceptions “may be granted” but does not explain how to request one or what the timeline looks like. One community member in the Reddit thread put it bluntly: “That’s how the bar already was before that commit, and yet, here we are.” The old flexible standard failed to stop the slop wave. The new standard solves that problem by moving all the discretion inside the team. What the Policy Does Not Apply To Two things worth noting for developers currently on Flathub: Existing apps are safe. Flathub explicitly confirmed it is not applying this policy retroactively. Apps already in the store can stay there, and their maintainers can keep updating them. The ban only applies to new submissions. The runtimes are exempt. Critics on Reddit pointed out that the runtimes bundled with Flatpak almost certainly contain AI-generated code, since the projects that make up those runtimes like GNOME and KDE libraries have accepted AI contributions. Flathub is not applying this policy to the runtimes themselves. The Broader Context: Linux Is Not Unified on This Flathub’s position is not representative of the entire Linux ecosystem. The community is visibly divided, and the splits are happening at major project level. Projects that ban or restrict AI contributions: NetBSD — Banned AI contributions, with the project openly citing licensing and IP concerns as the primary reason. OBS Studio — Has restrictions on AI-generated code in contributions. Zig — Restricts AI-generated contributions. Flathub — Now one of the most explicit bans in the ecosystem. Projects that allow AI contributions: Linux kernel — Red Hat proposed relaxing the kernel’s previous AI ban in a recent policy update. The new kernel stance allows AI assistance for tests, documentation, mechanical changes, and small bug fixes, with attribution required. The reasoning: no major IP lawsuits have materialized, so the risk calculus shifted. QEMU — Previously banned AI-generated code, but reversed course after Red Hat’s intervention. The kernel’s position comes with an honest acknowledgment of the trade-off. Red Hat’s proposal noted that “AI lowers the cost of producing a patch but does nothing to lower the cost of understanding and reviewing one; if anything it raises it, since a reviewer can no longer assume that the submitter has reasoned through every line.” Is This Policy Even Enforceable? Multiple developers in the Reddit discussion raised this question. The honest answer is: not really, not perfectly. There is no reliable technical test to determine whether a given piece of code was written with AI assistance. What maintainers can detect: - Presence of AGENTS.md or similar LLM agent configuration files in the repository - GitHub Copilot summary blocks in pull requests - Repositories with suspiciously short histories and high commit volumes - Code structure and documentation patterns that are statistically associated with LLM output What they cannot reliably detect: a developer who types out LLM-suggested code manually, uses AI for research without copying text, or runs AI-assisted vulnerability scanning without including the tool’s output in the codebase. Piotrowski’s bet is that the policy does not need to be perfectly enforceable. A hard-line rule deters casual slop submitters up front, reduces the volume of submissions that need to be examined, and gives reviewers a clean grounds for rejection when something looks wrong. The people most likely to be deterred are the ones Flathub is trying to deter. What Developers Are Actually Worried About The concerns from the developer community are not all bad-faith objections from vibe-coders. There are real questions being raised: Where does “AI-assisted” start? If a developer used a search engine that returned an AI-generated snippet in the results and adapted that code, does it count? What about GitHub Copilot autocomplete for a single variable name? What about proprietary apps? Slack, Spotify, and other closed-source apps on Flathub cannot be audited for AI usage. The policy as written applies to them equally, but there is no realistic enforcement mechanism. Does this discourage new legitimate projects? The “mature and well-maintained” exception effectively means new projects start with a disadvantage if they have used any AI tooling, even for documentation. Some developers argued that a time-gating requirement would accomplish the same goal more objectively. The Bottom Line Flathub’s new policy is deliberately broad and deliberately vague. That is not a bug, it is a feature. The maintainers tried a narrow, carefully worded policy and it got litigated by every vibe-coder who wanted to argue about exactly how much AI assistance was too much. The new policy closes that argument by shifting all the discretion to the reviewers. The real test is whether “exceptions may be granted for mature, well-maintained projects” gets applied consistently or turns into a closed-door system where only projects the core team already likes get through. That question will only get answered over the next several months. For now, if you are submitting a new app to Flathub and you used an LLM anywhere in the process, the official answer is no. If your app is already on Flathub, nothing changes. And if you are a burned-out open source maintainer drowning in slop PRs from people who have never looked at their own code, this probably feels overdue. The commit: 992f57b — flathub-infra/documentation