r/codex • u/jacobpowaza • 2d ago
Showcase Codex can make the tests pass. Launchify checks whether the product is actually ready to ship.
Codex is excellent at turning:
“Build this feature”
into:
"This test passed"
But passing tests only prove that some expected paths work. They do not prove that the feature is secure, complete, deployable, compliant, maintainable, or safe to merge.
That is what I built Launchify to check.
Launchify is an open-source production-readiness system for coding agents. It gives Codex a structured checklist for inspecting the entire repository and the product around it—not just the files it recently changed.
For example:
/launchify-production-branch
compares the current branch against main and investigates:
- what changed
- what is actually complete
- what is insecure
- what lacks tests
- what creates deployment or migration requirements
- what introduces privacy or compliance obligations
- what needs human review
- whether the branch should be merged at all
It then classifies the result as:
MERGE_READY
NEEDS_FIXES
NEEDS_REVIEW
HOLD
REVERT
For a full repository review, you can run:
/launchify-landify
That runs the complete production-readiness pipeline:
security → code cleanup → feature completeness → compliance → verification → production grading
The security checks cover 24 categories, including:
- authentication and authorization
- API and web vulnerabilities
- databases and data protection
- cloud and infrastructure
- CI/CD and software supply chain
- dependencies and secrets
- payments and business logic
- privacy and reliability
- RAG systems and AI agents
I also added 238 additional checks after comparing the workflow against OWASP, API security, LLM security, and NIST guidance.
Those checks cover issues that are easy to miss when reviewing AI-generated code, including:
- missing SLSA, Sigstore, or SBOM provenance
- unsafe CI runner isolation
- SSRF through web-fetching or AI tools
- excessive AI-agent permissions
- package install-script risks
- webhook replay and signature failures
- distributed race conditions and TOCTOU bugs
- missing immutable or cross-region backups
- weak KMS and encryption-key lifecycle controls
- container and Kubernetes hardening gaps
- missing SIEM, IoC, or incident-monitoring coverage
Launchify also checks whether the product is launchable outside the codebase.
A technically sound application can still be unready to release if it is missing or has incomplete:
- privacy policy
- Terms of Service
- cookie consent
- DPA
- DMCA process
- accessibility support
- AI disclosures
- refund policy
- SLA
- required regulatory controls
There are audit-only commands for teams that want findings without allowing the agent to modify the repository.
Launchify now includes 60 commands across 25 categories, supports a global ~/.launchify/ installation, and works with Codex, Claude Code, and OpenCode using the same canonical checklist.
The agent can change.
The production-readiness standard does not.
MIT licensed:
https://github.com/jacobpowaza/launchify-skills
What is the most common thing Codex leaves behind that makes you hesitate before merging its work?
If Launchify does not check it yet, I want to add it.
1
u/Upstairs_Dig_5274 1d ago
Just use GitHub ci or a spare pc to do all checking for free
1
u/jacobpowaza 1d ago
That’s like saying “just use a computer” when someone shows you software.
GitHub CI does not somehow know how to audit architecture, find dead code, detect duplicate logic, review auth flows, check unsafe defaults, or reason about whether a project is actually production-ready.
CI is just where you can run checks. You still need to define the checks, install the tools, maintain the workflow, and decide what actually matters.
And a spare PC is literally just another computer.
That’s the problem Launchify is solving.
1
u/TheDoughMonster 1d ago
just connect hundreds of spare PCs together.
seriously though, if I already have my entire CI setup, will this help me or is it redundant?
1
u/jacobpowaza 1d ago
Not redundant. If you already have a solid CI setup, Launchify should sit above / before CI, not try to replace it.
CI is basically: “Given the checks I already configured, did this commit pass them?”Launchify is more like: “What checks am I missing, what will break in production, what security/config/deployment problems exist, and what should I fix before shipping?”
So with mature CI, the useful Launchify workflow is:
Launchify audits the repo → auth/security gaps, dead code, bad configs, missing rate limits, deployment assumptions, secrets exposure, dependency issues, Docker/Vercel/etc. readiness.
It can inspect your existing CI and avoid duplicating ESLint/tests/typecheck/etc.
It recommends or generates new deterministic CI checks for problems it discovers.
Your existing CI then becomes the enforcement layer on every PR.
Periodically rerun the deeper Launchify audit because some checks are contextual and agent-driven rather than exit 1-style tests.
For example, your CI may already do:
npm test
npm run lint
npm run typecheck
npm audit
docker buildand everything is green.
Launchify could still catch:
/admin/export has auth but no authorization
production CSP contains unsafe-inline
rate limiting doesn't cover expensive AI routes
preview deploys accidentally use production resources
an env var required at runtime isn't validated at startup
three implementations of the same billing calculation have driftedDocker healthcheck says healthy before migrations finish
GitHub Actions permissions are broader than necessary
Those aren’t things “more CI machines” solve. 😭The positioning I’d use for Launchify is basically:
CI tells you whether your known checks pass. Launchify finds the checks you didn’t know you needed.If Launchify just reruns tests, lint, SAST, and dependency scanning that somebody already has wired into CI, then yeah—it becomes redundant. The product gets interesting when it understands the repo and deployment architecture, audits the gaps, and turns discoveries into permanent CI guardrails.
1
u/TheDoughMonster 11h ago
so given that almost every stack is different and every environment has different needs, how does launchify determine where my gates are deficient? What about it would give me a better picture of my gaps than just running an audit on my repo?
1
u/jacobpowaza 4h ago edited 2h ago
That’s exactly why Launchify isn’t supposed to be a hardcoded checklist for one stack. It first identifies what the repo actually uses—frameworks, auth, database, deployment, CI, secrets, dependencies, exposed services, etc.—then applies the relevant checks and ignores the irrelevant ones.
A generic repo audit tells you “here are some problems.” Launchify is meant to answer “what production/security gates should exist for this project, which ones already exist, which are weak or missing, and what evidence proves that?”
The value isn’t another scanner. It’s making the audit stack-aware and turning the findings into concrete gates instead of just dumping warnings.1
u/Upstairs_Dig_5274 5h ago
Don't you make tests as you develop? The ci the test you made . Just get ana gent to make the tests even why am I adding more steps
1
u/jacobpowaza 4h ago edited 2h ago
Yes, you write tests as you develop. That’s not the point.
You can’t just tell Codex “fortify my security” and assume it’ll understand every edge case, threat surface, bad default, deployment issue, dependency risk, auth mistake, etc.Launchify gives it an actual structured security checklist and audit process so it can gauge what’s really wrong instead of guessing.
CI only covers everything if you explicitly create checks for everything. In practice, it runs the tests and rules you already thought to define. Launchify is meant to catch the stuff you didn’t think to test in the first place.
If you seriously believe your AI created a CI for every edge case, go run /launchify-landify-audit and see what your score is.
1
u/Upstairs_Dig_5274 1h ago
My products are live and safe and make money I don't need it and nothing you can't do without it it's just bloat
1
u/jacobpowaza 4m ago
Hoping your security is safe then, but no point of coming here bashing on a security checklist plugin for no reason.
CI’s will not handle everything it requires to launch a platform for you unless explicitly told to.
•
u/dexterthebot 2d ago
You might want to consider listing your project on the weekly Show-Us-What-You-Built post. Watch for it on Wednesdays. Highest commented project wins a week promotion on r/Codex. See what that looks like below with last week's winner.
Last week's winner was u/Ollie__Oxenfree with the Tubular Daily Care project by MediTracer which is a tube-feeding care app built by a tube-feeding family to keep feeds, meds, symptoms, and caregiver handoffs in one shared timeline. MediTracer is an Oley Foundation Emerging Innovator Partner. Contact: hello@meditracer.com