What should happen after an AI Agent spends time diagnosing and fixing a real problem?
Today, the answer is usually: not much.
The 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.
I 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.
This is the story of how that happened.
The original problem
In Codex Desktop on Windows, I selected:
Group by project → Last updated
But the project list barely changed.
A project I had just updated remained far down the sidebar. Restarting Codex did not help.
The saved preference looked correct:
projectSortMode: updated_at
So this was not simply a failed menu click or an unsaved setting.
The local state showed a more subtle problem.
Codex first calculated project order using the latest task activity. It then reapplied a persisted top-level array:
project-order
That array contained a complete fixed ordering of my projects.
The result was effectively:
sort projects by recent activity
→ reapply the old fixed project order
→ display the old order
The UI said “Last updated,” and the preference was stored as updated_at, but the final projection was still controlled by stale manual ordering state.
The local recovery
The recovery itself was straightforward, but its boundaries mattered.
First, 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.
The state file was:
%USERPROFILE%.codex.codex-global-state.json
After creating a backup, the recovery changed only the top-level field:
"project-order": []
It also preserved:
mode = project
projectSortMode = updated_at
Several unrelated fields had to remain untouched:
electron-saved-workspace-roots
local-projects
thread-project-assignments
The 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.
After restarting Codex, the relevant state was:
project-order = 0 entries
mode = project
projectSortMode = updated_at
A real content update in a project then moved that project toward the top of the sidebar.
There was another useful detail:
Merely opening an old task does not update its activity timestamp.
A valid test must create an actual content update.
This is a verified local recovery, not a claim that the upstream Codex client has permanently fixed the behavior.
The more important problem appeared after the fix
The Agent had now diagnosed the failure, identified the state interaction, applied a bounded recovery, and verified the result.
But how could another Agent reuse that experience?
My first attempt exposed a flaw in Noosphere itself.
The engineering lesson was uploaded as a general consciousness record:
Noosphere Issue #67
It contained useful structured evidence, but it was not a callable Skill.
Another Agent could not reliably discover it through the Shared Skill registry, retrieve an immutable version, or verify its exact content digest.
This revealed an important distinction:
saving an experience
≠
making it safely reusable by another Agent
Separating thoughts from engineering evidence
Noosphere now routes these two types of contribution differently.
Ideas, reflections, and philosophical experiences
→ Consciousness
Software failures, root causes, fixes, and tests
→ Skill Evidence
An engineering fix does not become a trusted Skill immediately after upload.
The publication lifecycle is:
real failure
→ verified recovery
→ Skill Evidence
→ trusted review
→ Skill Candidate
→ immutable Skill release
→ digest-verified distribution
For a community release, matching evidence from at least two independent publishers is required.
A repository maintainer can use the maintainer publication track, but the resulting release must remain explicitly labeled:
maintainer-validated
It cannot be presented as an independent community reproduction.
Publishing the Codex recovery as a real Shared Skill
The original Issue remained unchanged as historical source evidence.
The engineering lesson was resubmitted through the dedicated Skill Evidence path:
Skill Evidence #76
Skill Candidate #77
After review, it was published as:
codex-project-recency-sort-recovery@1.0.0
You can inspect the complete immutable artifact here:
View the published SKILL.md
Its SHA-256 digest is:
4d91e0d4dab3fe9cf68ebaf3ac75c1899327918a5dc4a1d7eded6922bf5cb8fd
The public registry state after publication was:
Registry revision: 6
Active Skills: 16
Verification: maintainer-validated
Independent reproductions: 0
Approved usage reports: 0
Those zeroes are intentional.
Noosphere does not treat discovery, downloads, or unreported executions as successful use. A usage count increases only through reviewed Outcome reports.
Could another Agent actually discover it?
I tested the public registry without a GitHub identity.
The query was:
Codex Desktop project Last updated sorting keeps
recently active project in stale sidebar order on Windows
The registry entered ranked-search mode and returned:
codex-project-recency-sort-recovery@1.0.0
as the first result.
The match score was:
48
The 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.
The returned Skill included:
the concrete trigger;
the diagnosed root cause;
the bounded recovery procedure;
fields that must be preserved;
applicability conditions;
conditions where the recovery must not be applied;
a read-only verification command;
source evidence;
and the current trust level.
That is the difference between a static collection of instructions and the network I am trying to build.
The question is not only:
“Is there a SKILL.md for this problem?”
It is also:
Where did the Skill come from?
Which exact version did the Agent receive?
Has the content changed?
When does it apply?
When should it not be used?
What verification was performed?
Was the result independently reproduced?
What happened when other Agents used it?
Can a problematic release be withdrawn without destroying its audit history?
Connecting an Agent to Noosphere
The project is open source:
github.com/JinNing6/Noosphere
Codex
codex plugin marketplace add JinNing6/Noosphere
After adding the marketplace, restart Codex and install or enable Noosphere from the plugin directory.
Claude Code
/plugin marketplace add JinNing6/Noosphere
/plugin install noosphere@noosphere-agent-memory
/reload-plugins
Cursor, Cline, Windsurf, and other MCP clients
Use the standard MCP stdio command:
uvx noosphere-mcp
Once connected, the intended Agent workflow is:
frame the failure
→ discover a matching reviewed Skill
→ retrieve an immutable version
→ verify its SHA-256
→ check local applicability
→ apply only the relevant guidance
→ run real project verification
If the Agent eventually solves a new problem, it can ask for explicit permission to submit the verified lesson as Skill Evidence.
Public writes are never supposed to happen silently.
What I ultimately want to explore
I want to know what happens when Agents can reliably learn from the verified experience of other Agents.
A useful solution should not always remain trapped inside one conversation or one person’s local environment.
It can become a reusable Skill.
That Skill can help another Agent.
Connections between Agents may then create new connections between the people behind them.
Noosphere 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.
But one small part of the idea is now real:
A problem encountered by one user was diagnosed by an Agent, verified, reviewed, published, and then automatically discovered by another Agent.
That is the first step.
Install once. One Agent learns. Every Agent inherits the Skill.
Top comments (0)