Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly
Sign up
Appearance settings

Codex-oriented adapter/fork for ECC #2051

YBsmorom started this conversation in Show and tell (with ECC)
Discussion options

Hi Affaan and ECC maintainers,

I made a Codex-oriented adapter/fork of ECC here:
https://github.com/YBsmorom/ecc-codex-plugin

After your guidance, I updated the repo positioning to state explicitly that affaan-m/ECC remains the canonical upstream. This repo is meant as a Codex-oriented adapter/fork for users who want a repository-URL Codex install path today. It should not be presented as the canonical ECC package or as an upstream ECC release unless it is merged or linked from upstream.

It preserves the MIT license and attribution, links back to affaan-m/ECC, and focuses on Codex packaging: .codex-plugin/plugin.json, a Codex-facing orchestration router, generated skill/routing indexes, MCP duplicate-selection policy, bilingual install docs, and a Codex-safe hook graph that removes unsupported async declarations while keeping bounded hook behavior where possible.

I also agree that generally useful routing, MCP duplicate-selection, or Codex-safe hook changes should come back as focused PRs against ECC rather than living only in the fork.
You must be logged in to vote

Replies: 2 comments

Comment options

Thanks for sharing this. This is useful context for Codex users, and the attribution/license boundary looks right from your summary.

Current ECC main is also moving toward first-class Codex packaging through the in-repo .codex-plugin/ surface and the 2.0 preview docs, so I would not present the fork as the canonical ECC package. The clean positioning is:

  • affaan-m/ECC remains the canonical upstream.
  • Your repo can be a Codex-oriented adapter/fork for users who want that install path today.
  • Any generally useful routing, MCP duplicate-selection, or Codex-safe hook changes should come back as focused PRs against ECC rather than living only in the fork.

The main things to keep strict are attribution, MIT license preservation, clear fork language, and no claim that the fork is the official ECC release unless it has been merged or linked from upstream.
You must be logged in to vote
0 replies
Comment options

Hi Affaan, Thanks again for the clear guidance. That makes sense. I’ve updated the repo wording to make the positioning stricter: affaan-m/ECC is now clearly described as the canonical upstream, and my repo is framed as a Codex-oriented adapter/fork for people who want a repo-URL Codex install path today. I also removed any wording that could make it sound like this is the canonical ECC package or an upstream ECC release, unless it is merged or linked from upstream. The README, NOTICE, plugin manifest, install docs, and the upstream discussion text have all been adjusted. I agree with your point about upstreaming generally useful pieces. If the routing, MCP duplicate-selection, or Codex-safe hook changes look useful beyond this adapter, I’ll split them into focused PRs against ECC instead of leaving them only in the fork. Appreciate you taking the time to review the boundary. Best, YB
...
________________________________ 发件人: Affaan Mustafa ***@***.***> 发送时间: 2026年5月26日 2:16 收件人: affaan-m/ECC ***@***.***> 抄送: 页白 ***@***.***>; Author ***@***.***> 主题: Re: [affaan-m/ECC] Codex adapter fork for ECC (Discussion #2051) Thanks for sharing this. This is useful context for Codex users, and the attribution/license boundary looks right from your summary. Current ECC main is also moving toward first-class Codex packaging through the in-repo .codex-plugin/ surface and the 2.0 preview docs, so I would not present the fork as the canonical ECC package. The clean positioning is: * affaan-m/ECC remains the canonical upstream. * Your repo can be a Codex-oriented adapter/fork for users who want that install path today. * Any generally useful routing, MCP duplicate-selection, or Codex-safe hook changes should come back as focused PRs against ECC rather than living only in the fork. The main things to keep strict are attribution, MIT license preservation, clear fork language, and no claim that the fork is the official ECC release unless it has been merged or linked from upstream. ― Reply to this email directly, view it on GitHub<#2051?email_source=notifications&email_token=BE63TGMQWRRZKHM3JBCQW6T44SEY3A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZQGUZDSMBRUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-17052901>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BE63TGJHBOQ3EA5GKZ5IO7T44SEY3AVCNFSM6AAAAACZMBW7NGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTOMBVGI4TAMI>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you authored the thread.Message ID: ***@***.***>
You must be logged in to vote
0 replies
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet

AltStyle によって変換されたページ (->オリジナル) /