Apply for OpenAI Codex open-source maintainer support and API credits

[joshyorko]

Decision requested

Approve a project-level application to both OpenAI programs:

• Codex for Open Source for maintainer access, Codex support, API credits, and any available Codex Security access.
• Codex Open Source Fund for the full available $25,000 API-credit award, justified by the repository's unusually high upstream-change rate, native Linux engineering surface, and community maintenance load.

This is an application for codex-desktop-linux as shared open-source infrastructure, not for unrestricted personal usage and not for one contributor's experimental branch.

Strategic objective: replace reverse engineering with a sanctioned upstream path

The long-term request is not for OpenAI to permanently subsidize reverse engineering of a proprietary DMG. The repository's current conversion pipeline is evidence of three things:

1. There is meaningful Linux demand for Codex Desktop.
2. The community has already built the packaging, native integration, updater, test, and support infrastructure needed to help maintain a Linux product.
3. Continuing to patch opaque minified bundles is less secure, less reliable, and more expensive for everyone than a supported upstream relationship.

The preferred outcome is for OpenAI to choose the strongest collaboration model it can support:

Priority	Preferred upstream path	What it would unlock
1	Official OpenAI Linux build and release channel	Removes binary conversion entirely and gives Linux users first-class updates
2	Controlled source access for approved maintainers under an NDA, CLA, or contributor agreement	Lets trusted maintainers implement and review Linux support against real platform boundaries instead of minified output
3	Open-source or source-available platform adapter layer	Exposes windowing, desktop integration, plugin registration, settings, updater, and packaging contracts without disclosing unrelated proprietary product code
4	Supported Linux porting kit	Provides schemas, interfaces, source maps or symbols, build manifests, platform capability contracts, and test fixtures
5	Coordinated prerelease and engineering channel	Gives maintainers advance artifacts, release notes, known platform changes, and a responsible private path for security and compatibility findings
6	API credits and Codex access as an interim bridge	Funds the compatibility and safety work required while a more durable upstream path is evaluated

Full application source access would be the most direct maintenance path, but it is not the only useful outcome. Even access limited to the Electron platform abstraction, Linux-relevant native bridges, plugin contracts, settings registration, updater interfaces, and build/test harness would eliminate a large share of fragile bundle patching.

Why this is also better for OpenAI

• Reduces security risk from community patching of opaque production bundles.
• Preserves OpenAI's control over authentication, account entitlements, server-side rollouts, update integrity, and branding.
• Produces higher-quality Linux bug reports and tested fixes from contributors who already understand the platform matrix.
• Reduces duplicate reverse engineering after every upstream release.
• Creates a path to official Linux support without requiring OpenAI to staff the entire port immediately.
• Converts an unofficial compatibility project into a potential upstream contributor and validation community.
• Gives OpenAI a concrete, high-signal demonstration of Codex being used to expand access to Codex itself.

What OpenAI already receives from this community

This repository is already operating as an independent Linux engineering, compatibility, and field-testing group around Codex Desktop.

Contributors are not merely requesting a port. They are already doing work that would otherwise require upstream engineering, QA, support, security, and developer-relations capacity:

• Linux users report real failures with distro, desktop environment, display protocol, GPU, sandbox, browser, package, and session evidence.
• Contributors reproduce those reports and trace them across the upstream application, launcher, native modules, plugins, package payloads, and runtime state.
• Community developers implement Linux-native features and platform adapters rather than asking OpenAI to own every distro and compositor edge case.
• Maintainers review patches, reject stale compatibility paths, add regression tests, and repeatedly repair upstream drift.
• The project validates Computer Use, browser integration, accessibility, updater behavior, packaging, settings, remote control, and desktop lifecycle across environments OpenAI does not currently ship.
• Security-sensitive behavior around extraction, symlinks, native bridges, package installation, provenance, and rollback receives public review and test coverage.
• Documentation and troubleshooting convert individual failures into reusable support knowledge.
• The community identifies new upstream capabilities, distinguishes real platform blockers from server-side entitlements, and avoids bypassing OpenAI controls.
• The project provides OpenAI with a concentrated source of Linux product feedback, reproducible bug reports, implementation experiments, and potential upstream fixes.

The public activity supports that claim: GitHub lists 80 contributor accounts including automation, 455 merged pull requests, 153 closed issues, and an intense recent cycle of 239 PRs opened and 185 merged in 30 days. The project has already built a contributor pipeline, not just a proof of concept.

The reciprocal value proposition

OpenAI would not be funding a DMG extractor for its own sake. It would be supporting and formalizing an existing external Linux engineering community that:

• expands the reachable Codex developer audience;
• finds failures before an official Linux launch would;
• prototypes platform support at community cost;
• reduces the number of Linux-specific edge cases OpenAI must discover alone;
• can maintain Linux-owned adapters if given stable contracts and an appropriate collaboration boundary;
• provides a ready contributor and validation base for an eventual official Linux product.

A sanctioned relationship lets OpenAI retain ownership of the proprietary application, authentication, entitlements, release process, and security boundaries while the community continues to own much of the Linux-specific integration matrix.

The practical ask is reciprocity: the community is already contributing engineering and support value; OpenAI should help make that work safer, more efficient, and sustainable through access, interfaces, coordination, and credits.

Application-ready answer: why this community

OpenAI would not be starting a Linux ecosystem from zero. codex-desktop-linux already has an active contributor and user community that reports reproducible bugs, implements Linux-native features, reviews security-sensitive changes, tests packaging and desktop environments, and debugs upstream regressions. This work expands access to Codex while absorbing Linux-specific engineering and support effort that OpenAI does not currently staff publicly. Support would strengthen an existing contributor pipeline and create a practical upstream relationship: OpenAI keeps control of proprietary product and entitlement boundaries, while approved community maintainers help own Linux integration, validation, and feedback.

This issue should therefore open two conversations in parallel:

• Immediate: support the current maintenance burden with Codex access and API credits.
• Strategic: determine whether OpenAI can provide an official Linux build, controlled source access, a supported porting interface, or an engineering partnership.

This is an invitation to discuss an appropriate collaboration boundary, not a claim that the community is entitled to proprietary source code.

Application-ready answer: what support would be most valuable

The highest-leverage outcome would be a sanctioned upstream path for Linux rather than indefinite funding for reverse engineering. Ideally, OpenAI would ship an official Linux build or provide controlled source access to approved maintainers under an appropriate agreement. A narrower platform adapter, source maps, build manifests, interface contracts, prerelease artifacts, or a private engineering channel would also substantially reduce risk and duplicated effort. API credits and Codex access remain valuable as an immediate bridge: they would fund release analysis, compatibility fixes, security review, regression testing, and contributor support while OpenAI and the maintainers evaluate a durable upstream relationship.

Why this project is a strong fit

codex-desktop-linux gives Linux users a local, reproducible path to run Codex Desktop from an official upstream DMG without redistributing OpenAI application binaries. It is not a thin launcher. It maintains a cross-distribution build, patch, native-integration, packaging, update, security, and regression-testing system around an upstream application that changes rapidly and is not shipped for Linux.

The project directly expands access to OpenAI's developer tooling for users on Debian, Ubuntu, Pop!_OS, Mint, Elementary, Fedora, openSUSE, Arch, Manjaro, EndeavourOS, NixOS, atomic desktops, Wayland, and X11.

Live public project evidence

Live badges query GitHub through Shields and update automatically. Click each badge for its source view. Inventory-only values are explicitly marked as the 2026-07-10 snapshot.

Signal	Current evidence
Repository age	Created 2026-02-05
Stars
Forks
Watchers
Default-branch commits	1,283 at 2026-07-10 snapshot
Merged pull requests
Open pull requests
Closed non-PR issues
Open non-PR issues
Contributor accounts
Discussions	6 at 2026-07-10 snapshot
Tracked files on main	417 at 2026-07-10 snapshot
Main workflows	6 at 2026-07-10 snapshot
Main CI status

The recent maintenance rate is the clearest signal of need:

• 239 pull requests opened in the 30 days ending 2026-07-10.
• 185 pull requests merged in that period.
• 72 issues opened and 64 issues closed in that period.
• The repository has accumulated 455 merged PRs and 1,283 main-branch commits in about five months.

Snapshot-only figures and recent-period activity should be refreshed immediately before an application is submitted; live badges require no manual update.

What the repository actually maintains

1. Reproducible local conversion

• Downloads or accepts a user-supplied official Codex DMG.
• Extracts the Electron application and patches upstream macOS/Windows assumptions for Linux.
• Rebuilds native Node modules against a matching Linux Electron runtime.
• Records build provenance, upstream version, source, enabled features, and patch results.
• Uses explicit integrity and required-patch gates so an upstream drift cannot silently produce a falsely accepted build.
• Deliberately avoids distributing OpenAI application binaries.

2. Native Linux packaging and installation

• Debian/Ubuntu-family .deb packages.
• Fedora/openSUSE .rpm packages.
• Arch-family pacman packages.
• Nix, NixOS, and Home Manager integration.
• AppImage support for atomic and other distributions.
• Desktop entries, icons, URL-scheme handling, package lifecycle hooks, and guided native setup.
• A devcontainer and local CI path so contributors can reproduce builds without modifying their host OS.

3. Linux runtime and updater

• Managed Linux Node.js runtime with checksum validation.
• Codex CLI discovery, explicit binary selection, install/update preflight, and GUI-safe PATH handling.
• Rust update manager that polls upstream, validates downloads, rebuilds packages locally, coordinates privileged installation, and supports rollback.
• Wrapper-repository update detection, changelog presentation, feature selection, cache cleanup, notifications, and user-service integration.
• Launcher support for warm starts, single-instance coordination, tray behavior, webview supervision, and side-by-side identities.

4. Native Linux Computer Use

The Rust Computer Use backend is a substantial accessibility and desktop-control project, not a UI flag:

• AT-SPI accessibility-tree inspection.
• Screenshot capture.
• Absolute pointer and input support through Linux-native interfaces.
• Terminal and application identity integration.
• Window discovery, activation, target resolution, and focus verification.
• Backend registry for GNOME, KDE/KWin, Hyprland, i3, and COSMIC-class environments.
• GNOME Shell extension and COSMIC helper integration.
• Chrome native-messaging host and browser-profile diagnostics.
• Linux plugin staging and registration while preserving upstream account and rollout gates.

5. Additional parity and accessibility work

• Browser Use and Chrome integration.
• Linux Read Aloud native backend and plugin integration.
• Linux Record & Replay workflow for turning demonstrations into reusable skills.
• Remote-control and mobile-connection integration.
• Conversation, status, workspace, proxy, capture, opener, and updater UX integrations.
• File-manager and desktop-environment behavior.
• GPU, Vulkan, sandbox, Wayland, X11, and session compatibility.

6. Extensible feature framework

The repository provides a manifest-driven Linux feature system rather than forcing experimental integrations into core:

• ASAR patch descriptors.
• Declarative resources.
• Runtime hooks.
• Package hooks.
• Dependency and conflict validation.
• Target-aware distro, package-format, package-manager, desktop, and version matching.
• Ownership manifests so disabled features are removed cleanly.
• Preservation of enabled feature configuration through locally rebuilt updates.

Current main contains 23 entries under linux-features, including framework documentation/configuration and a broad portfolio of opt-in integrations. Optional features are disabled by default and must not bypass upstream entitlements.

7. Security and release engineering

The project handles high-risk boundaries that benefit directly from stronger automated analysis:

• Untrusted archive and ASAR extraction.
• Symlink and path-containment checks.
• Native bridge and native-messaging registration.
• Patch preflight and post-patch integrity verification.
• DMG hashes and provenance.
• Privileged package installation through a narrowly scoped boundary.
• Rollback and last-known-good package handling.
• Required-vs-optional patch policy.
• Cross-format payload and permission validation.
• Shell, JavaScript, Rust, packaging, and end-to-end smoke tests.

The maintenance problem Codex helps solve

Every upstream DMG can change minified bundle names, module boundaries, platform predicates, plugin metadata, native-app query shapes, settings routes, entitlements, and runtime behavior. A build may still launch while a Linux feature has silently disappeared or become mislabeled.

Recent concrete examples include drift affecting:

• Computer Use registration, install flow, native-app discovery, and settings visibility.
• Linux Desktop settings component resolution.
• Browser plugin reconciliation.
• Dictation and Read Aloud availability.
• Chronicle/Skysight status semantics.
• Mobile connection toggles and remote-control UI.
• New upstream capabilities such as Sites.
• Helper lifecycle and CLI resume behavior.
• Upstream DMG URL, version, and hash changes.

The project therefore needs more than ordinary code completion. It needs repeated, evidence-bound comparison of large minified applications, source tracing across shell/JavaScript/Rust/package layers, security review, regression-test generation, and cross-platform validation.

DMG intelligence as shared infrastructure

A major support target is a release-intelligence system that can answer, for each upstream build:

Category	Required answer
Linux patch drift	Which required or optional patch stopped matching, and where should it be repaired?
Feature staging drift	Did plugin metadata, resources, binaries, or runtime hooks disappear or move?
Platform-gated capability	Is a feature macOS-only, Windows-only, cross-platform, or already Linux-enabled?
New upstream capability	Is this a real new feature, framework noise, or entitlement-only bundle presence?
Entitlement/rollout gate	Is local support possible without bypassing a server-side account decision?
Runtime regression	Does installed/enabled state agree with what Desktop actually exposes?
Security regression	Can extraction, copying, patching, or staging escape its intended root?
Recommended owner	Which core patch, feature descriptor, native backend, launcher, updater, or package path should change?
Issue candidate	Is there enough evidence to open actionable Linux parity work?

Reports should bind every runtime claim to release, source, capture time, hash/provenance, and exact evidence. A missing or stale runtime snapshot must block acceptance rather than be converted into a false claim of parity.

This tool is valuable beyond one contributor: it reduces repeated reverse engineering for every maintainer and makes reviews reproducible.

Why OpenAI support would have high leverage

Credits would be used for bounded, auditable repository work where Codex materially reduces maintainer load:

1. Upstream release analysis

   • inspect each new DMG;
   • classify changed bundles, platform gates, plugins, native binaries, and bridge calls;
   • produce a reviewed compatibility and action report.

2. Regression repair

   • trace current upstream behavior;
   • write failing fixtures before patches;
   • implement current-shape fixes;
   • remove obsolete compatibility paths instead of accumulating permanent fallbacks.

3. Cross-platform verification

   • run JavaScript, Rust, shell, package, and smoke suites;
   • exercise representative distro, desktop, Wayland, and X11 combinations;
   • inspect generated package payloads and launchers.

4. Security review

   • audit extraction and containment;
   • inspect updater and privileged-install boundaries;
   • analyze native bridges and plugin staging;
   • use Codex Security if the program makes it available.

5. Community maintenance

   • reproduce issue reports;
   • review PRs and CI failures;
   • turn recurring failures into regression tests;
   • keep architecture, troubleshooting, and contributor documentation current.

6. New-feature assessment

   • detect upstream capabilities early;
   • separate bundle presence from entitlement;
   • create evidence-backed Linux implementation issues where appropriate.

The project is an unusually direct demonstration of Codex maintaining the infrastructure that makes Codex usable by more developers.

Proposed six-month work program

These are proposed targets, subject to maintainer approval.

Workstream A: upstream-release response

• Analyze every observed production DMG revision.
• Publish a provenance-bound drift report for each supported update.
• Maintain a table of Linux-supported, platform-specific, entitlement-gated, and issue-candidate capabilities.
• Target an initial drift assessment within 24 hours and an actionable maintainer report within 48 hours when volunteer availability permits.

Workstream B: compatibility and reliability

• Keep required patch preflights blocking on real failures.
• Add regression coverage for every accepted release-drift repair.
• Stabilize Computer Use registration, settings visibility, native-app discovery, and major compositor backends.
• Improve Browser, Read Aloud, Chronicle/Skysight, remote/mobile, and Linux settings diagnostics.
• Remove stale legacy matchers when a current upstream shape is established.

Workstream C: test matrix and release evidence

• Expand deterministic fixture coverage for minified-bundle drift.
• Exercise native package formats and representative desktop/session combinations.
• Produce machine-readable patch, rebuild, and runtime-health reports.
• Track flaky and environment-dependent failures separately from product regressions.

Workstream D: security hardening

• Preserve containment guarantees for extracted and copied application trees.
• Strengthen provenance and hash verification.
• Audit updater escalation, rollback, native messaging, and staged permissions.
• Establish a repeatable security-review checklist for release candidates.

Workstream E: contributor throughput

• Improve issue templates for runtime evidence and release provenance.
• Document the DMG intelligence workflow and owner mapping.
• Maintain concise contributor runbooks for focused and broad verification.
• Use credits for maintainer-approved triage, review, and documentation tasks.

Proposed credit request and allocation

Apply for the full available Open Source Fund award and available Codex for Open Source support.

Suggested allocation:

Share	Use
30%	Upstream DMG comparison, release intelligence, and compatibility diagnosis
25%	Regression implementation, tests, and cross-platform verification
20%	Security analysis and hardening
15%	Issue triage, PR review, CI diagnosis, and contributor support
10%	Evidence-backed evaluation of new upstream capabilities

The percentages are planning guardrails, not personal quotas.

Governance and accountability

Before submission, maintainers should approve a lightweight policy:

• Credits belong to the project maintenance effort.
• A maintainer-designated owner administers access.
• Usage is limited to public-repository work, approved private security investigation, CI/release analysis, and related documentation.
• No resale, account sharing, unrelated personal workloads, or entitlement bypass.
• Contributors receive access or sponsored runs based on approved issues/workstreams, not status.
• Security-sensitive findings remain private until responsibly handled.
• A public quarterly summary records workstreams, outcomes, and approximate credit usage without exposing account or billing details.
• Maintainers can revoke access or redirect allocation.
• Any unused credits remain unused rather than being spent to exhaust an award.

Application-ready project description

codex-desktop-linux is an MIT-licensed, community-maintained compatibility and delivery layer that lets Linux users build Codex Desktop locally from OpenAI's official macOS DMG without redistributing OpenAI binaries. In roughly five months, the project has reached 2,249 stars, 288 forks, 80 GitHub-listed contributor accounts, 1,283 main-branch commits, and 455 merged pull requests. It supports major Debian, Fedora, Arch, Nix, atomic-desktop, Wayland, and X11 environments through native packaging, a Rust updater, managed runtime tooling, a modular Linux feature framework, and native backends for Computer Use, Read Aloud, Record & Replay, browser integration, and desktop control. Because each upstream DMG can change minified bundles, platform gates, plugin contracts, and native behavior, maintainers perform continuous reverse engineering, security review, regression testing, and cross-distribution validation. OpenAI support would fund a shared DMG release-intelligence system, faster compatibility repairs, stronger security and package verification, and maintainer-approved community triage. The project does not redistribute OpenAI binaries or bypass account entitlements; support would be governed as project infrastructure with public outcome reporting.

Application-ready answer: why credits are needed

The project's highest recurring cost is reasoning over rapid upstream application drift. A single DMG update can move minified modules, change platform predicates, alter plugin registration, or leave the application launchable while Linux-only integrations silently disappear. Codex is well suited to comparing large bundles, tracing contracts across JavaScript, Rust, shell, packaging, and CI, generating focused regressions, and reviewing security-sensitive patches. Credits would let maintainers run this work consistently for every upstream release, broaden cross-platform verification, reduce issue and PR latency, and convert one-off reverse engineering into durable shared tooling. The requested support would be restricted to approved project maintenance and reported by workstream.

Application-ready answer: expected impact

The immediate impact is reliable Codex Desktop access for a growing Linux community across multiple distributions and desktop stacks. The durable impact is a reproducible release-intelligence and validation system that makes future upstream changes cheaper and safer to support. Success would be measured by provenance-bound reports for new DMGs, faster identification of compatibility blockers, regression tests for accepted fixes, improved Computer Use and accessibility reliability, stronger updater/extraction security, broader package/session validation, and reduced maintainer time spent rediscovering the same failures.

Public evidence links

• Repository
• README
• Architecture
• Build and packaging
• Linux features architecture
• Linux Computer Use
• Updater
• Contributing
• Actions
• Pull requests
• Issues

Submission checklist

• Primary maintainer approves applying to each program.
• Application owner and backup owner are named.
• Maintainers/contributors to list are agreed.
• Public metrics are refreshed on the submission date.
• Claims are checked against current main and linked evidence.
• Six-month priorities and success measures are approved.
• Credit governance and access rules are approved.
• Codex for Open Source application is submitted.
• Open Source Fund application requests the full available credit award.
• Submission details and follow-up owner are recorded privately.
• Public issue is updated with submission status, excluding private account or billing data.

Guardrails

• This is an unofficial community project.
• The project does not redistribute OpenAI application binaries.
• Users obtain the upstream application and build locally.
• The wrapper does not bypass OpenAI account entitlements, server-side rollouts, or security controls.
• The application must not imply OpenAI endorsement, privileged roadmap access, acquisition discussions, or ownership transfer.
• No private OpenAI account, organization, token, billing, or application-form data belongs in this issue.

[joshyorko]

@ilysenko, do you support applying to OpenAI's Codex OSS programs and exploring a sanctioned Linux collaboration path? I'm happy to prepare the applications and coordinate outreach, but I won't represent the project without your approval. Would you prefer to lead, delegate it to me, or not pursue it?

[ilysenko]

@joshyorko Thanks! I really like this idea.

Were you planning to turn this into an issue for the OpenAI repo?

If you don't mind, I'd prefer to submit it myself. Since I'm maintaining the Linux project, I think it makes the most sense for the proposal to come from the main repository.

Your draft is already a great starting point. If you're okay with it, I'll polish it a bit and use it as the basis for the issue, making sure to credit you for the idea.

[joshyorko]

@joshyorko Thanks! I really like this idea.

Were you planning to turn this into an issue for the OpenAI repo?

If you don't mind, I'd prefer to submit it myself. Since I'm maintaining the Linux project, I think it makes the most sense for the proposal to come from the main repository.

Your draft is already a great starting point. If you're okay with it, I'll polish it a bit and use it as the basis for the issue, making sure to credit you for the idea.

@ilysenko Waiting on your direction and I agree it should come from you

[ilysenko]

@joshyorko thanks, I'll also have Codex help me organize everything and fill out both application forms using its built-in browser.
I'll use your draft as the basis, and I'll include a link to this issue in the applications for additional context.

[ilysenko]

Done.

I submitted both applications using the two links you shared, and I'll also open an issue in the official Codex GitHub repository.

Hopefully this doesn't get us banned. 😄 I don't really expect OpenAI to give us anything, but if they do end up providing credits or tokens, we'll figure out a fair way to share them among the maintainers.

[ilysenko]

@joshyorko @Yo-DDV

I've also added you as collaborators

This is mostly a contingency plan. I'd still prefer to review and merge PRs myself whenever possible.

If I'm unavailable for more than a day—or if a missile happens to hit my apartment (which is a very real possibility 😅)—please don't let the project stall.

Otherwise, I'd ask that you only merge PRs if you're genuinely confident they're the right change, you've reviewed them carefully, and you've validated them with Codex using the highest reasoning effort available.

When in doubt, it's always better to wait for me or ask for a second opinion.

[Yo-DDV]

@ilysenko thanks for the trust. I get exactly what you mean here.

I’ll keep treating you as the person steering reviews and merges day to day. I’ll keep opening PRs, leaving the evidence in the right threads, and waiting for your review whenever that’s practical.

If you’re away and the project would otherwise sit blocked, I can help keep things moving, but only on changes I’ve actually reviewed and tested carefully. When I’m not sure, I’ll wait or ask for another look.

And @joshyorko, thanks again for kicking off the OpenAI support idea. It was a good push.

[mario-loomia]

Got so much from this repo already, great job everyone and love seeing the Linux spirit coming through 🙌

[avifenesh]

i agree with offer, you should do it, you deserve it, and we are doing great job for openai

[ilysenko]

https://www.reddit.com/r/codex/comments/1us9ty9/comment/owqjcbj/

[joshyorko]

https://www.reddit.com/r/codex/comments/1us9ty9/comment/owqjcbj/

Not gonna lie if they drop it tomorrow and make us obsolete I would be a little sad

[ilysenko]

I think they will review our repositories, and management will call them in and ask them to hand over all of their responsibilities to us.

[Yo-DDV]

https://www.reddit.com/r/codex/comments/1us9ty9/comment/owqjcbj/

That will mark the end of a great adventure...

[avifenesh]

https://www.reddit.com/r/codex/comments/1us9ty9/comment/owqjcbj/

We have features that are difficult to mimic. We knew that it might come at some point, but Linux is not only Ubuntu, and running apps doesn't mean computer use or browser control. This just happened with the Claude desktop app. Linux versions don't have computer use yet.