OpenAI 2026 hackathon

GreenTeamGo — the approval gate for Codex

Codex asks before it force-pushes, deletes, or pays. A human decides, and every yes, no, and timeout becomes a signed receipt anyone can verify offline.

Solo project by Ryan Cason · 0 likes · 0 comments

Archive position — measured, not model output

0 likes on Devpost

2,264 of the 7,856 archived projects have more likes, and 5,592 share exactly 0 — so this project's #4,397 place in the like-ranked listing is a tie-break inside that group, not a ranking.

Projects (log scale)

1
10
100
1k
10k
05,592
11,758
2285
3–4132
5–975
10+14

Likes on Devpost. ▲ marks this project's group.

Show the figures
LikesProjectsShare of archive
05,59271.2%
11,75822.4%
22853.6%
3–41321.7%
5–9751.0%
10+140.2%
Devpost like counts for all 7,856 archived projects, captured when this archive was built.

Executive Summary

What the company appears to be: GreenTeamGo is a human approval gate for Codex, a coding agent. It is a tool that requires human decision before risky actions are taken by Codex — such as force-pushing code, deleting files, or making payments. The system records each decision in a tamper-evident chain using cryptographic signing.

What changed: The project was submitted to the OpenAI 2026 hackathon and describes itself as a prototype built with TypeScript, Node.js, and OpenAI tools like Codex and GPT-5.6. It includes a monorepo structure, an MCP server for integration with Codex, and a web-based inbox for human approvals.

Single most important open question: Does GreenTeamGo have any real-world adoption or usage beyond the hackathon submission? The description contains no evidence of customers, revenue, or product-market fit beyond its own self-reporting.

Back to contents

What The Product Actually Is

The description states that GreenTeamGo is a human approval gate for Codex. It integrates with Codex via an MCP (Model Control Protocol) tool (request_approval) and stops execution until a human decides whether to allow or deny the action. Decisions are recorded in a chain of signed receipts using Ed25519 cryptography.

  • The system supports three outcomes:
    • Approve → sealed receipt, action proceeds.
    • Deny → sealed receipt, returned to Codex with optional reason.
    • Timeout → fail-closed; silence counts as denial.
  • Each decision is stored in a hash-linked chain that can be verified offline using greenteamgo-verify CLI.
  • The system uses:
    • Ed25519 signing
    • SHA-256 hashing
    • JSON serialization
    • Node.js, TypeScript, and OpenAI tools (Codex, GPT-5.6)

Inference: The product is a proof-of-concept or prototype built for a hackathon, not a commercial offering.

Back to contents

Positioning & Claim Evolution

The description positions GreenTeamGo as a solution to the problem of unobserved dangerous actions by AI agents like Codex. It emphasizes:

  • A human decision point before risky actions.
  • Permanent, verifiable records of decisions.
  • Tamper-evident logging without requiring server access.

It claims that:

  • Codex already asks before dangerous commands but does not retain those prompts.
  • GreenTeamGo ensures a different human on a different device makes the decision.
  • Every yes, no, and timeout becomes a signed receipt anyone can verify offline.

Inference: The positioning is framed around security, accountability, and auditability — not scalability or commercial viability.

Back to contents

Target Customer & ICP

The description does not explicitly state target customers or personas. However, it implies:

  • Developers using AI coding agents like Codex.
  • Teams concerned with risk control and compliance in automated workflows.
  • Organizations that want to track and verify decisions made by AI tools.

Inference: The likely ICP includes developers or engineering teams who use AI agents for code automation and are concerned about oversight, especially in production environments.

Back to contents

Business Model & Pricing Evidence

There is no evidence of pricing, monetization strategy, or business model. The description only mentions:

  • A prototype built for a hackathon.
  • No revenue, customer data, or funding rounds are mentioned.

Not evidenced

Back to contents

Technical & Delivery Signals

The project includes:

  • A 7-package TypeScript monorepo with 141 tests.
  • Integration with Codex via MCP protocol (request_approval, get_decision, list_pending).
  • Use of Ed25519 signing, SHA-256 hashing, and JSON serialization.
  • CLI tool for verifying receipt chains (greenteamgo-verify).
  • Natural-language policy compiler authored by Codex.
  • Web-based inbox UI for approvals.

Inference: The technical stack is consistent with a developer-focused prototype. It shows some engineering maturity but lacks production-grade features like device-bound signing or full decentralization.

Back to contents

Traction & Maturity Signals

The description states:

  • A 20-action chain was committed to the repo.
  • Out of 20 actions, 14 were auto-cleared by policy, and 6 required human input.
  • Two critical actions were denied: one force-push over main and one payment charge.
  • The system is reproducible and verifiable via CLI.

However:

  • No evidence of real-world usage or adoption beyond the hackathon.
  • No mention of customers, users, or feedback loops.
  • No data on how many teams might be using it or how often it is triggered.

Not evidenced

Back to contents

Competitive Context

The description does not reference competitors. It focuses on the unique value proposition of:

  • Human oversight for AI actions.
  • Tamper-evident logging.
  • Integration with Codex and OpenAI tools.

There is no indication of existing solutions in this space, nor any comparison to similar products or platforms.

Not evidenced

Back to contents

Key Risks & Red Flags

Key risks and red flags include:

  • Prototype-only: The system is described as a hackathon submission — not a commercial product.
  • Server-side key storage: Signing keys are stored on the server, meaning a compromised server could sign false history (though this is acknowledged).
  • No device-bound signing: Human devices do not co-sign receipts yet — a planned feature.
  • Limited scope: The system only handles Codex actions and does not scale beyond that.
  • Self-reported metrics: The 20-action chain is committed to the repo, but no external validation or usage data exists.

Inference: The project has strong technical foundations for a prototype but lacks commercial traction or scalability.

Back to contents

Diligence Questions To Ask The Founders

  1. What is the current status of GreenTeamGo beyond the hackathon submission?
  2. Are there any users or teams currently using this system in production?
  3. How does the team plan to address the server-side key storage vulnerability?
  4. Is device-bound signing (human co-signing) a near-term roadmap item?
  5. What is the intended business model for monetizing this tool?
  6. Has the team considered integrating with other AI agents beyond Codex?

Back to contents

Investment/Partnership Verdict

Not evidenced

The description provides no evidence of revenue, customers, or traction. It describes a prototype built for a hackathon, with strong technical execution but no commercial viability or market validation.

This is not a product ready for investment or partnership at this stage — it's an early-stage idea with potential, but without any demonstrated demand or business model.

Back to contents

Source

Submitted to the OpenAI 2026 hackathon on Devpost. Project home on DevPost.

The analysis above was generated by a language model from the project's own one-line description. It is not independent research and contains no verified traction, revenue or customer data.