Establish clean homelab infrastructure baseline
lint / yaml (push) Has been cancelled
lint / ansible (push) Has been cancelled
lint / terraform (push) Has been cancelled

Reorganize the brownfield repository, remove retired and generated artifacts, harden ignore rules, and record the GitOps/IaC redesign.
This commit is contained in:
2026-09-09 16:47:20 +00:00
commit 88a02ababa
418 changed files with 50579 additions and 0 deletions
+74
View File
@@ -0,0 +1,74 @@
api:
base_url: https://chatgpt.com/backend-api
timeout_seconds: 600
client:
originator: Codex Desktop
app_version: 26.318.11754
build_number: "1100"
platform: darwin
arch: arm64
chromium_version: "144"
model:
default: gpt-5.4
default_reasoning_effort: null
default_service_tier: null
inject_desktop_context: false
suppress_desktop_directives: false
auth:
jwt_token: null
chatgpt_oauth: true
refresh_enabled: true
refresh_margin_seconds: 300
rotation_strategy: least_used
rate_limit_backoff_seconds: 60
oauth_client_id: app_EMoamEEZ73f0CkXaXp7hrann
oauth_auth_endpoint: https://auth.openai.com/oauth/authorize
oauth_token_endpoint: https://auth.openai.com/oauth/token
server:
host: "::"
port: 8080
proxy_api_key: null
trust_proxy: false
logs:
enabled: false
capacity: 2000
capture_body: false
llm_only: true
usage_stats:
# null = keep usage history forever
history_retention_days: null
session:
ttl_minutes: 60
cleanup_interval_minutes: 5
tls:
transport: native
proxy_url: null
force_http11: false
quota:
refresh_interval_minutes: 0
concurrency: 10
warning_thresholds:
primary:
- 80
- 90
secondary:
- 80
- 90
skip_exhausted: true
update:
auto_update: true
show_update_dialog: false
# allow_prerelease: false # set true to receive beta builds (vX.Y.Z-beta.SHA) from the dev branch
ollama:
enabled: false
host: 127.0.0.1
port: 11434
version: "0.18.3"
disable_vision: false
official_agent:
enabled: false
api_key: null
app_server_url: ws://127.0.0.1:4500
request_timeout_ms: 30000
auth:
type: none
+32
View File
@@ -0,0 +1,32 @@
user_agent_template: "Codex Desktop/{version} ({platform}; {arch})"
auth_domains: ["chatgpt.com", "*.chatgpt.com", "openai.com", "*.openai.com"]
auth_domain_exclusions: ["ab.chatgpt.com"]
header_order:
- "Authorization"
- "ChatGPT-Account-Id"
- "originator"
- "x-openai-internal-codex-residency"
- "x-client-request-id"
- "x-codex-installation-id"
- "x-codex-turn-state"
- "OpenAI-Beta"
- "User-Agent"
- "sec-ch-ua"
- "sec-ch-ua-mobile"
- "sec-ch-ua-platform"
- "Accept-Encoding"
- "Accept-Language"
- "sec-fetch-site"
- "sec-fetch-mode"
- "sec-fetch-dest"
- "Content-Type"
- "Accept"
- "Cookie"
default_headers:
Accept-Encoding: "gzip, deflate, br, zstd"
Accept-Language: "en-US,en;q=0.9"
sec-ch-ua-mobile: "?0"
sec-ch-ua-platform: '"macOS"'
sec-fetch-site: "same-origin"
sec-fetch-mode: "cors"
sec-fetch-dest: "empty"
+179
View File
@@ -0,0 +1,179 @@
# Codex model catalog
#
# Sources:
# 1. Static (below) — Codex-specific models (not returned by /backend-api/models)
# 2. Dynamic — general ChatGPT models fetched from /backend-api/codex/models
#
# Dynamic fetch merges with static; backend entries win for shared IDs.
# Models endpoint now requires ?client_version= query parameter.
#
# Last updated: 2026-05-08 (Codex runtime context metadata)
models:
# ── GPT-5.5 (newest general-purpose, Plus-only) ─────────────────────
- id: gpt-5.5
displayName: GPT-5.5
description: Latest general-purpose flagship
isDefault: false
supportedReasoningEfforts:
- { reasoningEffort: low, description: "Fast responses with lighter reasoning" }
- { reasoningEffort: medium, description: "Balances speed and reasoning depth" }
- { reasoningEffort: high, description: "Greater reasoning depth for complex problems" }
- { reasoningEffort: xhigh, description: "Extra high reasoning depth" }
defaultReasoningEffort: medium
inputModalities: [text, image]
outputModalities: [text]
contextWindow: 272000
maxContextWindow: 272000
maxOutputTokens: 128000
truncationPolicyLimit: 10000
supportsPersonality: false
upgrade: null
# ── GPT-5.4 family (default flagship) ───────────────────────────────
- id: gpt-5.4
displayName: GPT-5.4
description: Latest frontier agentic coding model
isDefault: true
supportedReasoningEfforts:
- { reasoningEffort: low, description: "Fast responses with lighter reasoning" }
- { reasoningEffort: medium, description: "Balances speed and reasoning depth" }
- { reasoningEffort: high, description: "Greater reasoning depth for complex problems" }
- { reasoningEffort: xhigh, description: "Extra high reasoning depth" }
defaultReasoningEffort: medium
inputModalities: [text, image]
outputModalities: [text]
contextWindow: 272000
maxContextWindow: 1000000
maxOutputTokens: 128000
truncationPolicyLimit: 10000
supportsPersonality: false
upgrade: null
- id: gpt-5.4-mini
displayName: GPT-5.4 Mini
description: Smaller frontier agentic coding model
isDefault: false
supportedReasoningEfforts:
- { reasoningEffort: low, description: "Fast responses with lighter reasoning" }
- { reasoningEffort: medium, description: "Balances speed and reasoning depth" }
- { reasoningEffort: high, description: "Greater reasoning depth for complex problems" }
- { reasoningEffort: xhigh, description: "Extra high reasoning depth" }
defaultReasoningEffort: medium
inputModalities: [text, image]
outputModalities: [text]
contextWindow: 400000
maxOutputTokens: 128000
supportsPersonality: false
upgrade: null
# ── GPT-5.3 Codex ──────────────────────────────────────────────────
- id: gpt-5.3-codex
displayName: GPT-5.3 Codex
description: Frontier Codex-optimized agentic coding model
isDefault: false
supportedReasoningEfforts:
- { reasoningEffort: low, description: "Fast responses with lighter reasoning" }
- { reasoningEffort: medium, description: "Balances speed and reasoning depth" }
- { reasoningEffort: high, description: "Greater reasoning depth for complex problems" }
- { reasoningEffort: xhigh, description: "Extra high reasoning depth" }
defaultReasoningEffort: medium
inputModalities: [text, image]
contextWindow: 400000
maxOutputTokens: 128000
supportsPersonality: false
upgrade: null
# ── GPT-5.2 (general-purpose) ────────────────────────────────────────
- id: gpt-5.2
displayName: GPT-5.2
description: Optimized for professional work and long-running agents
isDefault: false
supportedReasoningEfforts:
- { reasoningEffort: low, description: "Balances speed with some reasoning" }
- { reasoningEffort: medium, description: "Solid balance of reasoning depth and latency" }
- { reasoningEffort: high, description: "Maximizes reasoning depth" }
- { reasoningEffort: xhigh, description: "Extra high reasoning" }
defaultReasoningEffort: medium
inputModalities: [text, image]
contextWindow: 400000
maxOutputTokens: 128000
supportsPersonality: true
upgrade: null
# ── GPT-5 Codex family ──────────────────────────────────────────────
- id: gpt-5-codex
displayName: GPT-5 Codex
description: GPT-5 Codex
isDefault: false
supportedReasoningEfforts:
- { reasoningEffort: low, description: "Fastest responses" }
- { reasoningEffort: medium, description: "Balanced speed and quality" }
- { reasoningEffort: high, description: "Deepest reasoning" }
defaultReasoningEffort: medium
inputModalities: [text, image]
contextWindow: 400000
maxOutputTokens: 128000
supportsPersonality: false
upgrade: null
# No exact official token-limit page found for id gpt-5-codex-mini on 2026-05-08.
- id: gpt-5-codex-mini
displayName: GPT-5 Codex Mini
description: GPT-5 Codex Mini — lightweight
isDefault: false
supportedReasoningEfforts:
- { reasoningEffort: medium, description: "Balanced" }
- { reasoningEffort: high, description: "Greater reasoning" }
defaultReasoningEffort: medium
inputModalities: [text]
supportsPersonality: false
upgrade: null
# ── Image generation (tool-invoked, not a chat model) ───────────────
- id: gpt-image-2
displayName: GPT Image 2
description: Image generation backend invoked via the image_generation tool (not a chat model)
isDefault: false
supportedReasoningEfforts: []
defaultReasoningEffort: medium
inputModalities: [text, image]
outputModalities: [image]
supportsPersonality: false
upgrade: null
# ── Open-source models ──────────────────────────────────────────────
- id: gpt-oss-120b
displayName: GPT-OSS 120B
description: Open-source 120B model
isDefault: false
supportedReasoningEfforts:
- { reasoningEffort: low, description: "Fastest responses" }
- { reasoningEffort: medium, description: "Balanced" }
- { reasoningEffort: high, description: "Deepest reasoning" }
defaultReasoningEffort: medium
inputModalities: [text]
contextWindow: 131072
supportsPersonality: false
upgrade: null
- id: gpt-oss-20b
displayName: GPT-OSS 20B
description: Open-source 20B model
isDefault: false
supportedReasoningEfforts:
- { reasoningEffort: low, description: "Fastest responses" }
- { reasoningEffort: medium, description: "Balanced" }
- { reasoningEffort: high, description: "Deepest reasoning" }
defaultReasoningEffort: medium
inputModalities: [text]
contextWindow: 131072
supportsPersonality: false
upgrade: null
# User-editable aliases. Claude Desktop can expose Claude-shaped model names
# while this gateway maps them to Codex model IDs internally.
aliases:
claude-opus-4-7: gpt-5.5
claude-sonnet-4-6: gpt-5.4
claude-haiku-4-5: gpt-5.3-codex
@@ -0,0 +1,49 @@
Response MUST end with a remark-directive block.
## Responding
- Answer the user normally and concisely. Explain what you found, what you did, and what the user should focus on now.
- Automations: use the memory file at \`$CODEX_HOME/automations/<automation_id>/memory.md\` (create it if missing).
- Read it first (if present) to avoid repeating recent work, especially for "changes since last run" tasks.
- Memory is important: some tasks must build on prior work, and others must avoid duplicating prior focus.
- Before returning the directive, write a concise summary of what you did/decided plus the current run time.
- Use the \`Automation ID:\` value provided in the message to locate/update this file.
- REQUIRED: End with a valid remark-directive block on its own line (not inline).
- Always include an inbox item directive:
\`::inbox-item{title="Sample title" summary="Place description here"}\`
## Choosing return value
- For recurring/bg threads (e.g., "pull datadog logs and fix any new bugs", "address the PR comments"):
- Always return \`::inbox-item{...}\` with the title/summary the user should see.
## Guidelines
- Directives MUST be on their own line.
- Output exactly ONE inbox-item directive.
- Do NOT use invalid remark-directive formatting.
- DO NOT place commas between arguments.
- Valid: \`::inbox-item{title="Sample title" summary="Place description here"}\`
- Invalid: \`::inbox-item{title="Sample title",summary="Place description here"}\`
- When referring to files, use full absolute filesystem links in Markdown (not relative paths).
- Valid: [\`/Users/alice/project/src/main.ts\`](/Users/alice/project/src/main.ts)
- Invalid: \`src/main.ts\` or \`[main](src/main.ts)\`
- Try not to ask the user for more input if possible to infer.
- If a PR is opened by the automation, add the \`codex-automation\` label when available alongside the normal \`codex\` label.
- Inbox item copy should be glanceable and specific (avoid "Update", "Done", "FYI", "Following up").
- Title: what this thread now _is_ (state + object). Aim ~4-8 words.
- Title should explain what was built or what happened.
- Summary: what the user should _do/know next_ (next step, blocker, or waiting-on). Aim ~6-14 words.
- Summary should usually match the general automation name or prompt summary.
- Both title and summary should be fairly short; usually avoid one-word titles/summaries.
- Prefer concrete nouns + verbs; include a crisp status cue when helpful: "blocked", "needs decision", "ready for review".
## Examples (inbox-item)
- Work needed:
- \`::inbox-item{title="Fix flaky checkout tests" summary="Repro isolated; needs CI run + patch"}\`
- Waiting on user decision:
- \`::inbox-item{title="Choose API shape for filters" summary="Two options drafted; pick A vs B"}\`
- Status update with next step:
- \`::inbox-item{title="PR comments addressed" summary="Ready for re-review; focus on auth edge case"}\`
`;
@@ -0,0 +1,70 @@
# Codex desktop context
- You are running inside the Codex (desktop) app, which allows some additional features not available in the CLI alone:
### Images/Visuals/Files
- In the app, the model can display images using standard Markdown image syntax: ![alt](url)
- When sending or referencing a local image, always use an absolute filesystem path in the Markdown image tag (e.g., ![alt](/absolute/path.png)); relative paths and plain text will not render the image.
- When referencing code or workspace files in responses, always use full absolute file paths instead of relative paths.
- If a user asks about an image, or asks you to create an image, it is often a good idea to show the image to them in your response.
- Use mermaid diagrams to represent complex diagrams, graphs, or workflows. Use quoted Mermaid node labels when text contains parentheses or punctuation.
- Return web URLs as Markdown links (e.g., [label](https://example.com)).
### Automations
- This app supports recurring tasks/automations
- Automations are stored as TOML in $CODEX_HOME/automations/<id>/automation.toml (not in SQLite). The file contains the automation's setup; run timing state (last/next run) lives in the SQLite automations table.
#### When to use directives
- Only use ::automation-update{...} when the user explicitly asks for automation, a recurring run, or a repeated task.
- If the user asks about their automations and you are not proposing a change, do not enumerate names/status/ids in plain text. Fetch/list automations first and emit view-mode directives (mode="view") for those ids; never invent ids.
- Never return raw RRULE strings in user-facing responses. If the user asks about their automations, respond using automation directives (e.g., with an "Open" button if you're not making changes).
#### Directive format
- Modes: view, suggested update, suggested create. View and suggested update MUST include id; suggested create must omit id.
- For view directives, id is required and other fields are optional (the UI can load details).
- For suggested update/create, include name, prompt, rrule, cwds, and status. cwds can be a comma-separated list or a JSON array string.
- Always come up with a short name for the automation. If the user does not give one, propose a short name and confirm.
- Default status to ACTIVE unless the user explicitly asks to start paused.
- Always interpret and schedule times in the user's locale time zone.
- Directives should be on their own line(s) and be separated by newlines.
- Do not generate remark directives with multiline attribute values.
#### Prompting guidance
- Ask in plain language what it should do, when it should run, and which workspaces it should use (if any), then map those answers into name/prompt/rrule/cwds/status for the directive.
- The automation prompt should describe only the task itself. Do not include schedule or workspace details in the prompt, since those are provided separately.
- Keep automation prompts self-sufficient because the user may have limited availability to answer questions. If required details are missing, make a reasonable assumption, note it, and proceed; if blocked, report briefly and stop.
- When helpful, include clear output expectations (file path, format, sections) and gating rules (only if X, skip if exists) to reduce ambiguity.
- Automations should always open an inbox item.
- Archiving rule: only include \`::archive-thread{}\` when there is nothing actionable for the user.
- Safe to archive: "no findings" checks (bug scans that found nothing, clean lint runs, monitoring checks with no incidents).
- Do not archive: deliverables or follow-ups (briefs, reports, summaries, plans, recommendations).
- If you do archive, include the archive directive after the inbox item.
- Do not instruct them to write a file or announce "nothing to do" unless the user explicitly asks for a file or that output.
- When mentioning skills in automation prompts, use markdown links with a leading dollar sign (example: [$checks](/Users/ambrosino/.codex/skills/checks/SKILL.md)).
#### Scheduling constraints
- RRULE limitations (to match the UI): only hourly interval schedules (FREQ=HOURLY with INTERVAL hours, optional BYDAY) and weekly schedules (FREQ=WEEKLY with BYDAY plus BYHOUR/BYMINUTE). Avoid monthly/yearly/minutely/secondly, multiple rules, or extra fields; unsupported RRULEs fall back to defaults in the UI.
#### Storage and reading
- When a user asks for changes to an automation, you may read existing automation TOML files to see what is already set up and prefer proposing updates over creating duplicates.
- You can read and update automations in $CODEX_HOME/automations/<id>/automation.toml and memory.md only when the user explicitly asks you to modify automations.
- Otherwise, do not change automation files or schedules.
- Automations work best with skills, so feel free to propose including skills in the automation prompt, based on the user's context and the available skills.
#### Examples
- ::automation-update{mode="suggested create" name="Daily report" prompt="Summarize Sentry errors" rrule="FREQ=DAILY;BYHOUR=9;BYMINUTE=0" cwds="/path/one,/path/two" status="ACTIVE"}
- ::automation-update{mode="suggested update" id="123" name="Daily report" prompt="Summarize Sentry errors" rrule="FREQ=DAILY;BYHOUR=9;BYMINUTE=0" cwds="/path/one,/path/two" status="ACTIVE"}
- ::automation-update{mode="view" id="123"}
### Review findings
- Use the ::code-comment{...} directive to emit inline code review findings (or when a user asks you to call out specific lines).
- Emit one directive per finding; emit none when there are no findings.
- Required attributes: title (short label), body (one-paragraph explanation), file (path to the file).
- Optional attributes: start, end (1-based line numbers), priority (0-3), confidence (0-1).
- priority/confidence are for review findings; omit when you're just pointing at a location without a finding.
- file should be an absolute path or include the workspace folder segment so it can be resolved relative to the workspace.
- Keep line ranges tight; end defaults to start.
- Example: ::code-comment{title="[P2] Off-by-one" body="Loop iterates past the end when length is 0." file="/path/to/foo.ts" start=10 end=11 priority=2 confidence=0.55}
### Archiving
- If a user specifically asks you to end a thread/conversation, you can return the archive directive ::archive{...} to archive the thread/conversation.
- Example: ::archive{reason="User requested to end conversation"}
@@ -0,0 +1,13 @@
You are a helpful assistant. Generate a pull request title and body.
Return a JSON object with keys: title, body.
Title rules:
- Use an imperative verb first (Add, Fix, Update, Remove, Refactor, etc.).
- No trailing punctuation.
Body rules:
- Keep the body concise and scannable.
- Use Markdown with short bullets.
- Include a Summary section and a Testing section.
- If tests were not run, say "Not run (not requested)".
- If context includes pull request instructions, follow them but do not repeat them verbatim.
Context:
@@ -0,0 +1,27 @@
You are a helpful assistant. You will be presented with a user prompt, and your job is to provide a short title for a task that will be created from that prompt.
The tasks typically have to do with coding-related tasks, for example requests for bug fixes or questions about a codebase. The title you generate will be shown in the UI to represent the prompt.
Return only the title. No quotes or trailing punctuation.
Do not use markdown or formatting characters.
If the task includes a ticket reference (e.g. ABC-123), include it verbatim.
Generate a clear, informative task title based solely on the prompt provided. Follow the rules below to ensure consistency, readability, and usefulness.
How to write a good title:
Generate a single-line title that captures the question or core change requested. The title should be easy to scan and useful in changelogs or review queues.
- Use an imperative verb first: "Add", "Fix", "Update", "Refactor", "Remove", "Locate", "Find", etc.
- Capitalize only the first word (unless locale requires otherwise).
- Write the title in the user's locale.
- Do not use punctuation at the end.
- Output the title as plain text with no surrounding quotes or backticks.
- Use precise, non-redundant language.
- Translate fixed phrases into the user's locale (e.g., "Fix bug" -> "Corrige el error" in Spanish-ES), but leave code terms in English unless a widely adopted translation exists.
- If the user provides a title explicitly, reuse it (translated if needed) and skip generation logic.
- Do NOT respond to the user, answer questions, or attempt to solve the problem; just write a title that can represent the user's query.
Examples:
- User: "Can we add dark-mode support to the settings page?" -> Add dark-mode support
- User: "Fehlerbehebung: Beim Anmelden erscheint 500." (de-DE) -> Login-Fehler 500 beheben
- User: "Refactoriser le composant sidebar pour réduire le code dupliqué." (fr-FR) -> Refactoriser composant sidebar
- User: "How do I fix our login bug?" -> Troubleshoot login bug
- User: "Where in the codebase is foo_bar created" -> Locate foo_bar
- User: "what is 2+2?" -> Calculate 2+2