Hi,
first of all, thank you for creating this project. I have been using it seriously and I think the idea has a lot of potential.
I wanted to open this issue before moving too far with a separate direction, because the repository appears to have been relatively inactive recently and I would prefer to coordinate rather than silently diverge.
Over the last period I have been preparing a larger set of changes that go beyond small bug fixes. The current work is shaping the project into a more capable agent-session bridge, with a much better developer and operator experience.
Some of the prepared changes include:
-
Distributed / multi-worker CAS deployments
The plugin is being extended beyond the original “single Codex endpoint” model. With multi-endpoint support, per-conversation endpoint selection, endpoint resolution policy, and node-aware routing, different chats or Discord threads can target different workers, machines, or environments.
This enables much more powerful setups: isolated project workers, dedicated heavy-task machines, parallel experiments, multi-node deployments, and cleaner separation between teams or conversations.
Related PRs:
-
Voice-driven coding and agent workflows
Audio messages can be transcribed before being forwarded into the agent session. This makes it possible to drive Codex from voice notes or spoken instructions in chat, which is a much more natural workflow for mobile use, hands-free operation, quick triage, and longer exploratory coding sessions.
Related PR:
-
Autonomous Codex worker tools
The plugin is also gaining worker-side tools that let Codex sessions inspect and interact with the app-server environment more directly, making sessions more autonomous and useful for real coding workflows.
Related PR:
-
Foundation for multiple agent backends
The architecture is moving beyond a Codex-only bridge and toward a more general chat-to-agent session layer, with room for Claude Code, OpenCode, ACP-compatible agents, and future providers.
-
Discord thread-aware session binding
Conversations can be scoped correctly per Discord thread, avoiding cross-talk between channels/threads and making it much safer to run multiple agent sessions in parallel.
Related PR:
-
Recovery for stale or missing bindings
The plugin can better recover from cases where OpenClaw still thinks a conversation is bound but the plugin-local state is missing or outdated. This makes long-running agent workflows much more reliable.
-
Improved reset/resume recovery flows
Resetting or resuming a conversation becomes a more practical recovery tool, helping users get unstuck without manual intervention and making day-to-day debugging clearer.
-
WebSocket transport profile improvements
Additional transport/profile support makes the plugin more flexible for real-world OpenClaw deployments.
Related PR:
Taken together, these changes make the project much more than a simple Codex bridge. They move it toward a general-purpose chat-to-agent session layer: one that can support multiple workers, multiple conversations, richer input types, better recovery, and eventually more backends such as Claude Code, OpenCode, ACP-compatible agents, and other future providers.
At this point, the number of changes is likely to become too large to manage comfortably as a long chain of separate PRs, so I wanted to ask about the future of the project.
I see two possible paths:
-
I help maintain this repository directly
If you are open to it, I would be happy to contribute more actively, help review/fix issues, and work on the roadmap here.
-
I continue in a public maintained fork
If you do not currently have time or interest to continue maintaining this repository, that is completely understandable. In that case, I would like to publish and maintain a fork, and I would prefer to do that transparently by linking it here so users know where active development is happening.
I am very open to whichever option works best for you.
My preference would be to collaborate here if possible, but I also want to keep the work moving forward and avoid accumulating a huge unreviewable PR stack.
Thanks again for the original work — I think there is a strong foundation here and I would like to help carry it forward.
Hi,
first of all, thank you for creating this project. I have been using it seriously and I think the idea has a lot of potential.
I wanted to open this issue before moving too far with a separate direction, because the repository appears to have been relatively inactive recently and I would prefer to coordinate rather than silently diverge.
Over the last period I have been preparing a larger set of changes that go beyond small bug fixes. The current work is shaping the project into a more capable agent-session bridge, with a much better developer and operator experience.
Some of the prepared changes include:
Distributed / multi-worker CAS deployments
The plugin is being extended beyond the original “single Codex endpoint” model. With multi-endpoint support, per-conversation endpoint selection, endpoint resolution policy, and node-aware routing, different chats or Discord threads can target different workers, machines, or environments.
This enables much more powerful setups: isolated project workers, dedicated heavy-task machines, parallel experiments, multi-node deployments, and cleaner separation between teams or conversations.
Related PRs:
Voice-driven coding and agent workflows
Audio messages can be transcribed before being forwarded into the agent session. This makes it possible to drive Codex from voice notes or spoken instructions in chat, which is a much more natural workflow for mobile use, hands-free operation, quick triage, and longer exploratory coding sessions.
Related PR:
Autonomous Codex worker tools
The plugin is also gaining worker-side tools that let Codex sessions inspect and interact with the app-server environment more directly, making sessions more autonomous and useful for real coding workflows.
Related PR:
Foundation for multiple agent backends
The architecture is moving beyond a Codex-only bridge and toward a more general chat-to-agent session layer, with room for Claude Code, OpenCode, ACP-compatible agents, and future providers.
Discord thread-aware session binding
Conversations can be scoped correctly per Discord thread, avoiding cross-talk between channels/threads and making it much safer to run multiple agent sessions in parallel.
Related PR:
Recovery for stale or missing bindings
The plugin can better recover from cases where OpenClaw still thinks a conversation is bound but the plugin-local state is missing or outdated. This makes long-running agent workflows much more reliable.
Improved reset/resume recovery flows
Resetting or resuming a conversation becomes a more practical recovery tool, helping users get unstuck without manual intervention and making day-to-day debugging clearer.
WebSocket transport profile improvements
Additional transport/profile support makes the plugin more flexible for real-world OpenClaw deployments.
Related PR:
Taken together, these changes make the project much more than a simple Codex bridge. They move it toward a general-purpose chat-to-agent session layer: one that can support multiple workers, multiple conversations, richer input types, better recovery, and eventually more backends such as Claude Code, OpenCode, ACP-compatible agents, and other future providers.
At this point, the number of changes is likely to become too large to manage comfortably as a long chain of separate PRs, so I wanted to ask about the future of the project.
I see two possible paths:
I help maintain this repository directly
If you are open to it, I would be happy to contribute more actively, help review/fix issues, and work on the roadmap here.
I continue in a public maintained fork
If you do not currently have time or interest to continue maintaining this repository, that is completely understandable. In that case, I would like to publish and maintain a fork, and I would prefer to do that transparently by linking it here so users know where active development is happening.
I am very open to whichever option works best for you.
My preference would be to collaborate here if possible, but I also want to keep the work moving forward and avoid accumulating a huge unreviewable PR stack.
Thanks again for the original work — I think there is a strong foundation here and I would like to help carry it forward.