augint-opencodex
augint-opencodex manages local Codex and OpenCode repository configuration from a
single tracked manifest, .ai-opencodex.json.
The current tool ships a real CLI with:
ai-opencodex initto create.ai-opencodex.jsonwhen needed and create any missing managed files without overwriting existing onesai-opencodex updateto merge rendered config into managed files, refresh generated docs and skills, and remove stale managed filesai-opencodex doctorto inspect manifest resolution, generated files, local ignore setup, and staged generated artifacts- a first-pass profile model with
augintandgov - local-only ignore handling through
.git/info/exclude
ai-opencodex is the preferred executable name. The published package still keeps
ai-codex as a compatibility alias.
The old sync workflow is now split into init and update.
Installation
For local development:
uv sync --group dev
Once the package is published, the intended install flows are:
uvx --from augint-opencodex ai-opencodex init
uv tool install augint-opencodex
ai-opencodex init
Manifest
This tool expects a tracked .ai-opencodex.json file in the target repository.
ai-opencodex initcreates the manifest from a bundled template when it is missing.ai-opencodex initnever overwrites an existing manifest; it warns and skips it.ai-opencodex updaterequires the manifest to already exist.
A generated starter manifest looks like this:
{
"$schema": "https://svange.github.io/augint-opencodex/ai-opencodex.schema.json",
"version": 1,
"profile": "augint",
"references": [],
"blocked_paths": [],
"content_policy": {
"no_emojis": true,
"no_ai_mentions": true
},
"shell_guardrails": {
"ask": [],
"deny": []
},
"patterns": {
"org_python_library": false
},
"opencode": {
"enabled": true,
"default_model": null,
"local_provider": {
"kind": "openai-compatible",
"name": "ollama",
"base_url": "http://host.docker.internal:11434/v1"
},
"models": [],
"bedrock": {
"enabled": false,
"models": []
}
},
"codex": {
"provider": "openai",
"model": null,
"approval_policy": null,
"sandbox_mode": null,
"web_search": null
}
}
The primary schema lives in
schemas/ai-opencodex.schema.json.
OpenCode and Codex manifest fields
The opencode and codex sections let the manifest fully express non-secret
local tool configuration:
opencode.local_provider- OpenAI-compatible local endpoint (for example Ollama) rendered asprovider.<name>.options.baseURLinopencode.jsonopencode.default_model- top-levelmodelinopencode.jsonopencode.models- curated catalog attached to the local provideropencode.bedrock.enabled/opencode.bedrock.models- toggles theamazon-bedrockprovider entry with the listed model IDscodex.provider-openaioraws; emitted as a runtime hint in.codex/config.tomlcodex.model,codex.approval_policy,codex.sandbox_mode,codex.web_search- override the defaults carried by the active profile
Commands
Initialize a repository:
uv run ai-opencodex init
Preview initialization without writing:
uv run ai-opencodex init --dry-run
Update managed files from the manifest:
uv run ai-opencodex update
Preview pending updates without writing:
uv run ai-opencodex update --dry-run
Fail if managed files are out of date:
uv run ai-opencodex update --check
Inspect the current repository state:
uv run ai-opencodex doctor
Update semantics
init is create-only:
- creates
.ai-opencodex.jsonif it is missing - creates any missing managed files
- skips existing files with a warning instead of overwriting them
update is merge-oriented:
- reads
.ai-opencodex.json - merges structured config files such as
opencode.jsonand.codex/config.toml - refreshes generated markdown and skill files from bundled templates
- lets new managed values win conflicts
- removes stale managed files that are no longer expected
Templates and generated skills
Bundled template assets now live under src/augint_opencodex/templates/ instead
of being embedded inline in renderer code.
That includes:
- the manifest starter template
- generated
.codex/config.tomland.ai-opencodex.mdtemplates - the generated
opencode.jsontemplate shell - the shared skills README template
- the org Python tooling skill file, including valid YAML frontmatter
Generated files
The current tool manages:
.ai-opencodex.md.codex/config.tomlopencode.json.agents/skills/README.md.agents/skills/org-python-tooling/SKILL.mdwhenpatterns.org_python_libraryis enabled
Managed outputs are added to .git/info/exclude by default so target
repositories do not need to commit them.
Canonical ownership
There is one source of truth for each managed file and one tool responsible for runtime-only behavior.
| File | Owner | Notes |
|---|---|---|
.ai-opencodex.json |
user (tracked) | Source of truth for managed files |
opencode.json |
augint-opencodex |
Repo root; managed |
.codex/config.toml |
augint-opencodex |
Repo root; managed |
.ai-opencodex.md |
augint-opencodex |
Repo root; managed |
.agents/skills/** |
augint-opencodex |
Managed |
Managed files should not be hand-edited unless you intend those edits to be
merged or replaced on the next ai-opencodex update.
Runtime ownership (augint-shell)
augint-shell is responsible only for runtime and container behavior:
- bind-mounting
.codex/andopencode.jsoninto the container - injecting secrets (
OPENAI_API_KEY, AWS credentials) at launch time - selecting Bedrock vs OpenAI auth paths based on the manifest's
codex.provider/opencode.bedrock.enabledsignals - CLI launch flags (
ai-shell opencode,ai-shell codex)
augint-shell should not ship duplicate template copies of opencode.json or
.codex/config.toml, and .ai-shell.yaml should not duplicate the shape of
.ai-opencodex.json.
Dogfooding this repo
This repository is set up to dogfood the generated instructions flow without a
root AGENTS.md.
- Keep
.ai-opencodex.jsontracked in the repo root. - Run
uv run ai-opencodex updateto generate.ai-opencodex.md,.codex/config.toml, and the other local-only artifacts. - Start Codex with
CODEX_HOME=$(pwd)/.codex codexso Codex uses the generated.codex/config.tomlas its home config and discovers.ai-opencodex.mdviaproject_doc_fallback_filenames.
Avoid creating a root AGENTS.md here. Codex checks AGENTS.md before fallback
filenames in the same directory, so a root AGENTS.md would shadow
.ai-opencodex.md and split Codex from the generated OpenCode instructions.
Development
make install
make test
make format
make typecheck
make build
Metadata
Release files for augint-opencodex 0.21.1
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| augint_opencodex-0.21.1.tar.gz | 24.9 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| augint_opencodex-0.21.1-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 61.8 kB
Release files / augint_opencodex-0.21.1.tar.gz
| Download URL | augint_opencodex-0.21.1.tar.gz |
|---|---|
| Size | 24.9 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
7c5e543f7e66519654144ea2abca2a1385626fca718636f9de7b2f12b64109d5
|
|
BLAKE2b-256 checksum How to use checksums |
5af5d4f7802b2b618575b6626ccf2c6a814041a8fdb951ae4b8d0c1f29a65622
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.13
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Aug 1, 2026.
Transparency logRelease files / augint_opencodex-0.21.1-py3-none-any.whl
| Download URL | augint_opencodex-0.21.1-py3-none-any.whl |
|---|---|
| Size | 36.9 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
950a359ecba1a4f0d0d8bba8591b743501464a7c6ca1487286d7e41f987de7e8
|
|
BLAKE2b-256 checksum How to use checksums |
d55dfb44e6140694b9b67534ebdb721d8af7542d51410aff61453ecfa8bfef35
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.13
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Aug 1, 2026.
Transparency log