Codex in Buffaly
Buffaly gives teams a local, inspectable way to use AI agents for real development work. It can work with Codex where Codex is the right execution environment, and it can also replace many everyday Codex workflows when you want Buffaly's local memory, Windows/.NET tooling, durable project context, and native actions.
Buffaly is not merely a Codex wrapper. It is an extensible local agent system with its own source, tools, history, ontology, provider configuration, and workflow discipline. For supported installations, Buffaly can also create and manage Codex-backed subagents so Codex can do delegated work while Buffaly remains responsible for the parent session, planning, validation, and commit discipline.
What Buffaly and Codex each do
Use Buffaly directly
Use Buffaly directly when the work benefits from Buffaly's local source, project memory, stored chat history, native tools, and Windows/.NET-oriented workflows. Buffaly is especially useful for enterprise codebases, long-running projects, operational development, repeatable local automation, and cases where you want the agent's supporting context to stay on your machine.
Use Codex from inside Buffaly
Use Codex from inside Buffaly when you want Codex to perform a bounded delegated task in a Codex child environment. In that model, Buffaly manages the parent agent, session history, planning, validation steps, and commit discipline. Codex does the delegated work. The Codex child environment has Codex capabilities, but it does not have the full Buffaly tool surface, durable Buffaly memory system, or Buffaly-native actions.
Key separation principle: Buffaly can use Codex, but Buffaly is broader than Codex. It can use native tools and actions instead of relying only on MCP, can use MCP when helpful, can switch providers where configured, and stores chat history and memories locally on the user's machine.
Authentication and providers
Buffaly supports more than one way to reach model providers. For OpenAI API usage, Buffaly can be configured with an OpenAI API key. For Codex-style workflows, Codex CLI must be installed and authenticated separately.
Where supported and configured, Buffaly can also use ChatGPT/Codex-style account authentication through the Codex backend/profile route. That account-based route is separate from an OpenAI API key. In practical terms, this means a Buffaly installation may support normal Buffaly completions through a configured Codex backend/profile route, while API-key-based OpenAI usage remains a different credential path.
Relevant documentation
Use the provider and authentication documentation for the current supported behavior in your installation. Provider support, backend routes, and account-auth behavior should be treated as available only when configured and supported by the installed Buffaly version.
Why use Buffaly directly
Buffaly can replace many tasks people normally use Codex for because it is built as a local agent environment rather than a thin prompt window.
Teams can understand and adapt the agent environment.
Workflows are shaped around local enterprise codebases.
Project context survives across sessions.
Local workflows do not need to rely only on MCP.
MCP remains available when it is the right integration path.
Model access can switch where configured, and chat history and memories are stored locally on the user's machine.
These features are most useful when the agent needs to remember project conventions, coordinate repeated development workflows, or use tools that are part of the local Buffaly environment.
When to let Buffaly create Codex subagents
Use Codex subagents for bounded implementation or investigation tasks that fit Codex well and can be delegated from a parent Buffaly workflow.
- Inspect a focused part of a repository and report findings.
- Implement a narrow change in a clearly owned set of files.
- Compare two possible approaches while Buffaly keeps the main plan and history intact.
- Run a Codex-oriented development task after Buffaly has prepared the context and constraints.
In this model, Buffaly stays in charge of the larger workflow. It keeps the parent session, history, planning context, validation checklist, and commit discipline. The Codex child does the assigned work and returns results to Buffaly.
Use Buffaly directly instead when the task depends on Buffaly-native memories, ontology, local actions, project-specific tools, provider switching, or the full Buffaly UI and tool surface.
Requirements
For Codex workflows inside Buffaly, make sure these requirements are met:
- Codex CLI is installed.
- Codex CLI is authenticated.
codex --versionworks in the environment where Buffaly will call Codex.codex loginhas been completed for the Codex account you intend to use.- Codex Embedded web module is installed.
- The default Buffaly installer includes the Codex Embedded module for supported installations.
- If you want normal Buffaly completions to use a Codex backend/profile route, the provider/auth route must be configured for that installation.
If Codex CLI is not installed or authenticated, Buffaly can still be used directly with other configured providers, but Codex-backed workflows will not be available until the Codex requirements are met.
Open Codex Embedded
For supported installations with the Codex Embedded module installed:
- Open
/web-modules/CodexEmbedded/index.html. - Use the Start button.
- Select Open Codex Embedded UI.
- The embedded UI opens at
/web-modules/CodexEmbedded/server/.
The module UI is the local entry point for starting and opening the embedded Codex experience from Buffaly.
Safe first workflow
Start with a small, reversible workflow before delegating larger changes:
- Confirm Codex CLI works with
codex --version. - Confirm account authentication with
codex login. - Open
/web-modules/CodexEmbedded/index.html. - Start the module and open
/web-modules/CodexEmbedded/server/. - Ask Buffaly to inspect a small documentation or code area.
- Have Buffaly create a focused Codex subagent only for a bounded task.
- Review the returned changes or findings.
- Run the validation commands appropriate for the project.
- Commit only the intended files after review.
This keeps the first run low-risk while confirming the local installation, authentication route, and delegated workflow.
Example prompts
Use Buffaly directly
Inspect the local project notes and explain the safest implementation path for this feature. Do not edit files yet.Update the documentation page for this workflow using the existing site style. Keep the change limited to the docs and static HTML files.Use Buffaly to manage a Codex subagent
Create a Codex subagent to inspect the authentication docs and report the exact requirements for using Codex inside Buffaly. Keep it read-only.Have a Codex subagent implement the small helper in the owned service file only, then bring the diff back for review before validation.Use Buffaly when provider/auth configuration matters
Check whether this Buffaly installation is configured for OpenAI API key usage or a Codex backend/profile route, and explain which credential path applies.Practical decision guide
| Path | When to choose |
|---|---|
| Buffaly directly | When you need local memory, local history, native Buffaly tools, Windows/.NET workflows, provider flexibility, or long-running project continuity. |
| Codex subagent | When the work is bounded, Codex is the preferred execution environment, and Buffaly can provide the parent planning context and validation discipline. |
| OpenAI API-key configuration | When the installation is intended to call OpenAI through API credentials. |
| Codex backend/profile route | Only where supported and configured. It is separate from an OpenAI API key. |