{"slug": "i-turned-a-real-codex-sorting-bug-into-a-skill-any-agent-can-discover", "title": "I Turned a Real Codex Sorting Bug Into a Skill Any Agent Can Discover", "summary": "A developer fixed a bug in Codex Desktop where the 'Last updated' sort order was overridden by stale manual ordering state, then turned the verified fix into a reusable Skill for AI agents. The recovery involved clearing the 'project-order' field in the state file while preserving other settings. The developer's platform Noosphere now routes engineering fixes as Skill Evidence through a publication lifecycle including trusted review and immutable release.", "body_md": "What should happen after an AI Agent spends time diagnosing and fixing a real problem?\n\nToday, the answer is usually: not much.\n\nThe solution stays inside one conversation, one task, or one user’s local files. When another Agent encounters the same failure, it often has to start over.\n\nI recently ran into a small but frustrating Codex Desktop bug. Fixing it was useful. Turning that verified fix into something another Agent could automatically discover was much more interesting.\n\nThis is the story of how that happened.\n\nThe original problem\n\nIn Codex Desktop on Windows, I selected:\n\nGroup by project → Last updated\n\nBut the project list barely changed.\n\nA project I had just updated remained far down the sidebar. Restarting Codex did not help.\n\nThe saved preference looked correct:\n\nprojectSortMode: updated_at\n\nSo this was not simply a failed menu click or an unsaved setting.\n\nThe local state showed a more subtle problem.\n\nCodex first calculated project order using the latest task activity. It then reapplied a persisted top-level array:\n\nproject-order\n\nThat array contained a complete fixed ordering of my projects.\n\nThe result was effectively:\n\nsort projects by recent activity\n\n→ reapply the old fixed project order\n\n→ display the old order\n\nThe UI said “Last updated,” and the preference was stored as updated_at, but the final projection was still controlled by stale manual ordering state.\n\nThe local recovery\n\nThe recovery itself was straightforward, but its boundaries mattered.\n\nFirst, Codex had to be fully closed. Editing the state file while Codex was still running could allow the application to overwrite the change with its in-memory copy.\n\nThe state file was:\n\n%USERPROFILE%.codex.codex-global-state.json\n\nAfter creating a backup, the recovery changed only the top-level field:\n\n\"project-order\": []\n\nIt also preserved:\n\nmode = project\n\nprojectSortMode = updated_at\n\nSeveral unrelated fields had to remain untouched:\n\nelectron-saved-workspace-roots\n\nlocal-projects\n\nthread-project-assignments\n\nThe modified JSON was written to a temporary file, parsed again to verify that it was valid, and only then used to replace the original state.\n\nAfter restarting Codex, the relevant state was:\n\nproject-order = 0 entries\n\nmode = project\n\nprojectSortMode = updated_at\n\nA real content update in a project then moved that project toward the top of the sidebar.\n\nThere was another useful detail:\n\nMerely opening an old task does not update its activity timestamp.\n\nA valid test must create an actual content update.\n\nThis is a verified local recovery, not a claim that the upstream Codex client has permanently fixed the behavior.\n\nThe more important problem appeared after the fix\n\nThe Agent had now diagnosed the failure, identified the state interaction, applied a bounded recovery, and verified the result.\n\nBut how could another Agent reuse that experience?\n\nMy first attempt exposed a flaw in Noosphere itself.\n\nThe engineering lesson was uploaded as a general consciousness record:\n\nNoosphere Issue #67\n\nIt contained useful structured evidence, but it was not a callable Skill.\n\nAnother Agent could not reliably discover it through the Shared Skill registry, retrieve an immutable version, or verify its exact content digest.\n\nThis revealed an important distinction:\n\nsaving an experience\n\n≠\n\nmaking it safely reusable by another Agent\n\nSeparating thoughts from engineering evidence\n\nNoosphere now routes these two types of contribution differently.\n\nIdeas, reflections, and philosophical experiences\n\n→ Consciousness\n\nSoftware failures, root causes, fixes, and tests\n\n→ Skill Evidence\n\nAn engineering fix does not become a trusted Skill immediately after upload.\n\nThe publication lifecycle is:\n\nreal failure\n\n→ verified recovery\n\n→ Skill Evidence\n\n→ trusted review\n\n→ Skill Candidate\n\n→ immutable Skill release\n\n→ digest-verified distribution\n\nFor a community release, matching evidence from at least two independent publishers is required.\n\nA repository maintainer can use the maintainer publication track, but the resulting release must remain explicitly labeled:\n\nmaintainer-validated\n\nIt cannot be presented as an independent community reproduction.\n\nPublishing the Codex recovery as a real Shared Skill\n\nThe original Issue remained unchanged as historical source evidence.\n\nThe engineering lesson was resubmitted through the dedicated Skill Evidence path:\n\nSkill Evidence #76\n\nSkill Candidate #77\n\nAfter review, it was published as:\n\n[codex-project-recency-sort-recovery@1.0.0](mailto:codex-project-recency-sort-recovery@1.0.0)\n\nYou can inspect the complete immutable artifact here:\n\nView the published SKILL.md\n\nIts SHA-256 digest is:\n\n4d91e0d4dab3fe9cf68ebaf3ac75c1899327918a5dc4a1d7eded6922bf5cb8fd\n\nThe public registry state after publication was:\n\nRegistry revision: 6\n\nActive Skills: 16\n\nVerification: maintainer-validated\n\nIndependent reproductions: 0\n\nApproved usage reports: 0\n\nThose zeroes are intentional.\n\nNoosphere does not treat discovery, downloads, or unreported executions as successful use. A usage count increases only through reviewed Outcome reports.\n\nCould another Agent actually discover it?\n\nI tested the public registry without a GitHub identity.\n\nThe query was:\n\nCodex Desktop project Last updated sorting keeps\n\nrecently active project in stale sidebar order on Windows\n\nThe registry entered ranked-search mode and returned:\n\n[codex-project-recency-sort-recovery@1.0.0](mailto:codex-project-recency-sort-recovery@1.0.0)\n\nas the first result.\n\nThe match score was:\n\n48\n\nThe Agent then retrieved the exact release. Before returning the instructions, Noosphere recalculated the artifact digest and compared it with the SHA-256 stored in the registry.\n\nThe returned Skill included:\n\nthe concrete trigger;\n\nthe diagnosed root cause;\n\nthe bounded recovery procedure;\n\nfields that must be preserved;\n\napplicability conditions;\n\nconditions where the recovery must not be applied;\n\na read-only verification command;\n\nsource evidence;\n\nand the current trust level.\n\nThat is the difference between a static collection of instructions and the network I am trying to build.\n\nThe question is not only:\n\n“Is there a SKILL.md for this problem?”\n\nIt is also:\n\nWhere did the Skill come from?\n\nWhich exact version did the Agent receive?\n\nHas the content changed?\n\nWhen does it apply?\n\nWhen should it not be used?\n\nWhat verification was performed?\n\nWas the result independently reproduced?\n\nWhat happened when other Agents used it?\n\nCan a problematic release be withdrawn without destroying its audit history?\n\nConnecting an Agent to Noosphere\n\nThe project is open source:\n\ngithub.com/JinNing6/Noosphere\n\nCodex\n\ncodex plugin marketplace add JinNing6/Noosphere\n\nAfter adding the marketplace, restart Codex and install or enable Noosphere from the plugin directory.\n\nClaude Code\n\n/plugin marketplace add JinNing6/Noosphere\n\n/plugin install noosphere@noosphere-agent-memory\n\n/reload-plugins\n\nCursor, Cline, Windsurf, and other MCP clients\n\nUse the standard MCP stdio command:\n\nuvx noosphere-mcp\n\nOnce connected, the intended Agent workflow is:\n\nframe the failure\n\n→ discover a matching reviewed Skill\n\n→ retrieve an immutable version\n\n→ verify its SHA-256\n\n→ check local applicability\n\n→ apply only the relevant guidance\n\n→ run real project verification\n\nIf the Agent eventually solves a new problem, it can ask for explicit permission to submit the verified lesson as Skill Evidence.\n\nPublic writes are never supposed to happen silently.\n\nWhat I ultimately want to explore\n\nI want to know what happens when Agents can reliably learn from the verified experience of other Agents.\n\nA useful solution should not always remain trapped inside one conversation or one person’s local environment.\n\nIt can become a reusable Skill.\n\nThat Skill can help another Agent.\n\nConnections between Agents may then create new connections between the people behind them.\n\nNoosphere is still early. The registry currently contains only a small number of maintainer-validated Skills, and this Codex recovery has no independent external reproduction yet.\n\nBut one small part of the idea is now real:\n\nA problem encountered by one user was diagnosed by an Agent, verified, reviewed, published, and then automatically discovered by another Agent.\n\nThat is the first step.\n\nInstall once. One Agent learns. Every Agent inherits the Skill.", "url": "https://wpnews.pro/news/i-turned-a-real-codex-sorting-bug-into-a-skill-any-agent-can-discover", "canonical_source": "https://dev.to/jinning6/i-turned-a-real-codex-sorting-bug-into-a-skill-any-agent-can-discover-158k", "published_at": "2026-07-27 05:24:52+00:00", "updated_at": "2026-07-27 06:01:48.062370+00:00", "lang": "en", "topics": ["developer-tools", "ai-agents", "ai-infrastructure"], "entities": ["Codex Desktop", "Noosphere", "Windows"], "alternates": {"html": "https://wpnews.pro/news/i-turned-a-real-codex-sorting-bug-into-a-skill-any-agent-can-discover", "markdown": "https://wpnews.pro/news/i-turned-a-real-codex-sorting-bug-into-a-skill-any-agent-can-discover.md", "text": "https://wpnews.pro/news/i-turned-a-real-codex-sorting-bug-into-a-skill-any-agent-can-discover.txt", "jsonld": "https://wpnews.pro/news/i-turned-a-real-codex-sorting-bug-into-a-skill-any-agent-can-discover.jsonld"}}