agentleFS
OpenClawAndroidOpenClawAndroid/openclaw-android-assistant/.agents/skills/codex-app-parity/SKILL.md

codex-app-parity

Skill556 starsChanged 35 days agoMITView on GitHub

Use when implementing or changing user-visible behavior/UI in this repository and parity with the installed Codex desktop app must be validated before coding.

3 other projects use a version of this, 2 of them edited.

Adopted by

Most recently taken up by

The file

Show its rules and text

We split this skill into the rules it gives an agent

26 rules. About 0 are common, 22 are distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈22

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this skill for any feature work or user-visible behavior/UI change in this repository.

    line 8
  2. Distinctive:

    Do not use it for purely internal refactors that do not affect behavior.

    line 9
  3. Distinctive:

    Ensure behavior is implemented with Codex.app as the source of truth, then verified with headless Playwright and screenshots.

    line 13
  4. Distinctive:

    Do not implement first and compare later.

    line 24
  5. Very specific:

    i18n keys: Search locale files (webview/assets/zh-TW-*.js, webview/assets/en-*.js, etc.) for human-readable labels.

    line 61
  6. Very specific:

    API calls and endpoints: Search main process files (.vite/build/main-*.js) for endpoint URLs, auth handling, and IPC channels.

    line 65
  7. Very specific:

    Icon names: Search for icon imports like audiowave-dark.svg, book-open-dark.svg.

    line 70
  8. Very specific:

    Keyboard shortcuts: Search for CmdOrCtrl+, Cmd+, keydown, keyCode, or specific key names.

    line 72
  9. Distinctive:

    Start with i18n locale files — they have human-readable labels that identify features.

    line 76
  10. Distinctive:

    Use the i18n key to find the component in the main bundle.

    line 77
  11. Distinctive:

    Check the main process bundle for any server-side proxying or Electron IPC handling.

    line 79
  12. Distinctive:

    Prefer Codex.app behavior over novel design.

    line 108
  13. Distinctive:

    Keep deviations minimal and intentional.

    line 109
  14. Distinctive:

    If deviating, include a short reason in the final response.

    line 110
  15. Distinctive:

    Verify parity after implementation:

    line 112
  16. Distinctive:

    Run local build/tests.

    line 114
  17. Distinctive:

    If Codex.app cannot be inspected (missing app, extraction/search failure) or has no equivalent pattern:

    line 127
  18. Distinctive:

    Use best local implementation consistent with existing repository patterns.

    line 130
  19. Distinctive:

    Keep behavior conservative and avoid speculative UX innovations.

    line 131
  20. Distinctive:

    Prefer minimal patches that align with app behavior rather than large refactors.

    line 137
  21. Distinctive:

    After completing a task that changes behavior or UI, always run a Playwright verification in headless mode.

    line 141
  22. Distinctive:

    Always capture a screenshot of the changed result and display that screenshot in chat when reporting completion.

    line 142
  23. Distinctive:

    After each feature implementation session that uses this skill:

    line 146
  24. Distinctive:

    Update search instructions: If new search techniques were used (e.g., a better way to extract minified code, new file locations), update …

    line 149
  25. Distinctive:

    Update architecture notes: If new IPC channels, API endpoints, or data flows were discovered, add them to the Architecture Notes.

    line 150
  26. Distinctive:

    Run Playwright in headless mode and capture a screenshot showing sidebar order.

    line 166

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Codex App Parity Skill

Use this skill for any feature work or user-visible behavior/UI change in this repository. Do not use it for purely internal refactors that do not affect behavior.

Objective

Ensure behavior is implemented with Codex.app as the source of truth, then verified with headless Playwright and screenshots.

Project Instructions

Codex.app-First Development Policy

For every new feature and every behavior/UI change, treat the installed desktop app as the source of truth:

  • App path: /Applications/Codex.app
  • Primary bundle to inspect: /Applications/Codex.app/Contents/Resources/app.asar

Do not implement first and compare later. Compare first, then implement.

How to Search for Features in Codex.app

Extraction

Extract the app bundle once (reuse if already extracted):

mkdir -p /tmp/codex-app-extracted
npx asar extract "/Applications/Codex.app/Contents/Resources/app.asar" /tmp/codex-app-extracted

Key Directories

DirectoryContents
/tmp/codex-app-extracted/webview/assets/Main frontend bundle (index-*.js) + locale files
/tmp/codex-app-extracted/.vite/build/Electron main process (main.js, main-*.js, preload.js, worker.js)
/tmp/codex-app-extracted/package.jsonApp metadata, version, entry point

Searching the Minified Bundle

The main UI bundle is a single large minified JS file at webview/assets/index-*.js. Use Python to search since grep -o with large repeat counts fails on macOS:

python3 -c "
with open('/tmp/codex-app-extracted/webview/assets/index-<hash>.js', 'r') as f:
    content = f.read()
idx = content.find('YOUR_SEARCH_TERM')
if idx >= 0:
    print(content[max(0, idx-200):idx+500])
"

What to Search For

  1. i18n keys: Search locale files (webview/assets/zh-TW-*.js, webview/assets/en-*.js, etc.) for human-readable labels. Keys follow the pattern component.feature.property (e.g., composer.dictation.tooltip).
  2. Component functions: Minified React components follow patterns like function X4n({prop1:t,prop2:e,...}). Search for the feature's i18n key to find the component that renders it.
  3. API calls and endpoints: Search main process files (.vite/build/main-*.js) for endpoint URLs, auth handling, and IPC channels. Key patterns:
    • prodApiBaseUrl → production API base (e.g., https://chatgpt.com/backend-api)
    • devApiBaseUrl → dev API base (e.g., http://localhost:8000/api)
    • fetch-request / fetch-response → IPC-proxied HTTP calls from renderer to main process
  4. Icon names: Search for icon imports like audiowave-dark.svg, book-open-dark.svg. Icon mapping is in the main bundle around the Hwn=Object.assign({ pattern.
  5. Keyboard shortcuts: Search for CmdOrCtrl+, Cmd+, keydown, keyCode, or specific key names.

Search Strategy

  1. Start with i18n locale files — they have human-readable labels that identify features.
  2. Use the i18n key to find the component in the main bundle.
  3. Trace the component to find hooks/composables, API calls, and event handlers.
  4. Check the main process bundle for any server-side proxying or Electron IPC handling.

Architecture Notes

  • Renderer → Main Process: The renderer uses a Uu HTTP client class that sends fetch-request IPC messages to the main process. The main process class tle handles these, adds auth tokens, and uses electron.net.fetch to make actual HTTP calls.
  • Auth: Auth tokens come from the app-server's getAuthStatus RPC method (ChatGPT backend auth).
  • App-server: A codex app-server child process communicating via JSON-RPC over stdin/stdout. Our bridge middleware proxies RPC calls to it.
  • Config constants: R7 = prodApiBaseUrl (https://chatgpt.com/backend-api), I7 = devApiBaseUrl (http://localhost:8000/api), C7 = originator (Codex Desktop).

Required Workflow (Feature Work)

  1. Identify target behavior:
  • Restate what behavior is being added/changed.
  • Define whether it is: data mapping, runtime event handling, UX text, visual treatment, interaction model, or all of these.
  1. Inspect Codex.app before coding:
  • Locate the implementation in app.asar (extract and search built assets as needed).
  • Find relevant strings/keys/functions/components for the feature (status labels, event names, item types, summaries, collapse/expand behavior, etc.).
  • Capture the closest equivalent pattern if exact parity is not present.
  1. Build a parity checklist from Codex.app:
  • Data model shape (fields used by UI).
  • Realtime event sources and transitions.
  • Rendering structure (what is shown collapsed vs expanded).
  • Copy/text behavior (phrasing and status wording).
  • Interaction behavior (auto-expand, auto-collapse, click/keyboard handling).
  • Visibility rules (when elements appear/disappear).
  1. Implement against that checklist:
  • Prefer Codex.app behavior over novel design.
  • Keep deviations minimal and intentional.
  • If deviating, include a short reason in the final response.
  1. Verify parity after implementation:
  • Confirm each checklist item.
  • Run local build/tests.
  • Re-check UI behavior against Codex.app reference.

Response Requirements (When delivering feature changes)

For feature tasks, include:

  • Codex.app analysis: what was inspected (files/areas/patterns).
  • Parity result: matched items and any explicit deviations.
  • Fallback note only if Codex.app could not be inspected or had no equivalent.

Fallback Rules

If Codex.app cannot be inspected (missing app, extraction/search failure) or has no equivalent pattern:

  • State the blocker explicitly.
  • Use best local implementation consistent with existing repository patterns.
  • Keep behavior conservative and avoid speculative UX innovations.

Scope and Safety

  • This policy applies to feature behavior and UX decisions, not just styling.
  • Bug fixes should still check Codex.app when they affect user-visible behavior.
  • Prefer minimal patches that align with app behavior rather than large refactors.

Completion Verification Requirement

  • After completing a task that changes behavior or UI, always run a Playwright verification in headless mode.
  • Always capture a screenshot of the changed result and display that screenshot in chat when reporting completion.

Self-Improvement Protocol

After each feature implementation session that uses this skill:

  1. Record new findings: Append a dated ## Findings: section documenting any newly discovered Codex.app internals (state keys, API endpoints, component patterns, auth flows, etc.).
  2. Update search instructions: If new search techniques were used (e.g., a better way to extract minified code, new file locations), update the "How to Search for Features" section.
  3. Update architecture notes: If new IPC channels, API endpoints, or data flows were discovered, add them to the Architecture Notes.
  4. Keep findings actionable: Each finding should include enough detail that a future session can reuse it without re-discovering.

Findings: Workspace Root Ordering (2026-02-25)

  • Codex.app persists workspace root ordering/labels in global state JSON keys:
    • electron-saved-workspace-roots (order source of truth)
    • electron-workspace-root-labels
    • active-workspace-roots
  • In this environment, persisted file path is:
    • ~/.codex/.codex-global-state.json
  • In packaged desktop runs, equivalent userData path is typically:
    • ~/Library/Application Support/Codex/.codex-global-state.json
  • For folder/project reorder parity, prefer reading these keys over browser LocalStorage-only ordering.
  • Validation requirement for reorder changes:
    • Run build/typecheck.
    • Run Playwright in headless mode and capture a screenshot showing sidebar order.

Findings: Dictation / Microphone Feature (2026-02-26)

  • i18n keys: composer.dictation.* — tooltip is "Hold to dictate", aria is "Dictate".
  • Component: M4n React hook handles recording state, audio capture, and transcription.
  • Audio pipeline: navigator.mediaDevices.getUserMedia({ audio: { channelCount: 1 } }) → MediaRecorder → chunks → Blob → multipart POST.
  • Transcription endpoint: The renderer sends audio to /transcribe via the IPC fetch proxy. The main process (tle class) prepends the prodApiBaseUrl (https://chatgpt.com/backend-api) and attaches ChatGPT auth bearer tokens. Full URL: https://chatgpt.com/backend-api/transcribe.
  • Request format: Multipart form-data with boundary ----codex-transcribe-<uuid>, fields: file (audio blob) and optional language. Body is base64-encoded and sent with X-Codex-Base64: 1 header.
  • Response: { text: "transcribed text" }.
  • Interaction model: Press-and-hold to record → release to stop and transcribe → text inserted into composer. Has "insert" and "send" modes.
  • Icon: audiowave-dark.svg / audiowave-light.svg (custom SVG, not from icon library).
  • Web app implementation: Our bridge proxies /codex-api/transcribe to the ChatGPT backend using auth tokens from the app-server getAuthStatus RPC. Frontend uses useDictation composable with MediaRecorder API.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.