DOCSEARCHbyAlgolia
Submit Docs

Every Code Documentation

repository·main·Indexed 25 days ago

https://github.com/just-every/code

A fast, local coding agent for the terminal and community-driven fork of openai/codex. It features multi-agent orchestration (Auto Drive), browser integration, MCP support, and a TUI with fuzzy file search. The project includes a suite of Rust crates for core business logic (codex-core), Git workspace snapshotting (codex-git-tooling), process hardening (codex-process-hardening), and a dedicated responses API proxy for secure OpenAI API key management.

Tokens
151.9K
Snippets
284
Records
863
Agent score
86%

What's inside Every Code

  1. Overview of OpenAI product snapshots

    main

    The following OpenAI products and APIs are supported within the context of this skill:

    • Apps SDK: Build ChatGPT apps using web component UIs and MCP servers.
    • Responses API: A unified endpoint for stateful, multimodal, tool-using agentic workflows.
    • Chat Completions API: Generate model responses from a list of conversation messages.
    • Codex: OpenAI's coding agent for software development (writing, understanding, reviewing, and debugging code).
    • gpt-oss: Open-weight reasoning models (gpt-oss-120b and gpt-oss-20b) under Apache 2.0.
    • Realtime API: Low-latency, multimodal speech-to-speech experiences.
    • Agents SDK: A toolkit for building agentic apps with tool use, context, and agent hand-offs.

  2. Overview of code_file_search

    main
    code_file_search is a fast fuzzy file search tool designed for Codex. It performs directory traversal while respecting .gitignore files and other ignore patterns using the ignore crate. It then uses the nucleo-matcher crate to perform fuzzy matching of a user-supplied PATTERN against the discovered file list.

  3. Overview of codex_file_search

    main
    codex_file_search is a fast fuzzy file search tool designed for Codex. It performs directory traversal while respecting .gitignore files and other ignore patterns using the ignore crate. It then performs fuzzy matching of a user-supplied PATTERN against the discovered file list using the nucleo-matcher crate.

  4. Overview of codex-tools

    main
    codex-tools is a shared support crate designed for building, adapting, and executing model-visible tools outside of codex-core. It provides host-facing tool models, discovery models, and adapters that are shared across multiple consumers in the ecosystem.

  5. Overview of codex-protocol

    main

    The codex-protocol crate defines the data types used for communication within the Codex ecosystem. It serves two primary purposes:

    1. Internal Types: Facilitates communication between codex-core and codex-tui.
    2. External Types: Defines the types used for interaction with codex app-server.

    The crate is designed to be lightweight with minimal dependencies and avoids containing business logic, preferring the use of Ext-style traits in other crates to extend functionality.

  6. Overview of argument-comment-lint

    main

    An isolated Dylint library designed to enforce specific Rust argument comment patterns using the /*param*/ shape. It aims to improve call-site readability when idiomatic API changes (like enums or newtypes) are not feasible.

    It provides two specific lints:

    • argument_comment_mismatch (defaults to warn): Ensures that a /*param*/ comment matches the actual parameter name of the callee.
    • uncommented_anonymous_literal_argument (defaults to allow): Flags anonymous literal-like arguments (e.g., None, true, false, or numeric literals) that lack a preceding /*param*/ comment.

    Note: String and char literals are exempt. The sole non-self method argument is also exempt if the method name matches the parameter name (e.g., .enabled(false) where the parameter is named enabled).

  8. Understand the code-protocol crate purpose

    main

    The code-protocol crate defines the communication types for the Codex ecosystem. It serves two primary roles:

    1. Internal Types: Facilitates communication between code-core and code-tui.
    2. External Types: Defines the interface used with codex app-server.

    To maintain stability and minimal dependency overhead, this crate is designed to contain only type definitions and should avoid implementing material business logic. Functionality should instead be added to these types in other crates using Ext-style traits.

  9. Understand the Memory Pipeline Architecture

    main

    The memory system operates in two distinct asynchronous phases to transform session rollouts into structured, consolidated memory artifacts. The runtime orchestration for these phases is located in codex-rs/core/src/memories/.

    Phase 1: Rollout Extraction (Per-thread)

    This phase processes individual rollouts to create structured memory records. It selects eligible rollouts from the state DB based on source, age, and idle time, then uses a model to extract:

    • raw_memory: Detailed memory content.
    • rollout_summary: A compact summary.
    • rollout_slug: An optional identifier.

    Phase 2: Global Consolidation

    This phase consolidates Phase 1 outputs into filesystem artifacts and runs a consolidation agent. It uses a global lock to ensure only one process mutates the memory workspace at a time. It performs:

    • Artifact syncing (raw_memories.md and rollout_summaries/).
    • Workspace diffing via phase2_workspace_diff.md.
    • Running a consolidation sub-agent to update high-level outputs like MEMORY.md, memory_summary.md, and skills/.

  10. Use mcp-types for Model Context Protocol implementation

    main

    The mcp-types crate provides Rust type definitions for the Model Context Protocol (MCP). These types are inspired by lsp-types and are designed to align with the official MCP specification.

    When implementing MCP in Rust, use these types to ensure compatibility with the protocol's TypeScript and JSON schemas. The implementation follows the specification version 2025-06-18.

  11. Understand codex app-server core primitives

    main

    The API is built around three core primitives that represent user-agent interactions:

    • Thread: A conversation between a user and the Codex agent, containing multiple turns.
    • Turn: A single exchange in a conversation (typically a user message followed by an agent message), containing multiple items.
    • Item: The individual components of a turn (e.g., user messages, agent reasoning, agent messages, shell commands, or file edits) used as context for future turns.

  12. Understand Image Generation Skill modes

    main

    The imagegen skill operates in two distinct modes depending on the user's requirements and available configuration:

    1. Default built-in tool mode (preferred): Uses the built-in image_gen tool for standard generation, editing, and simple transparent-image requests. This mode does not require an OPENAI_API_KEY.
    2. Fallback CLI mode: Uses the scripts/image_gen.py CLI. This mode is used only when explicitly requested by the user or when a true model-native transparency fallback (using gpt-image-1.5) is confirmed. This mode requires an OPENAI_API_KEY.

    CLI Subcommands: When using the Fallback CLI mode, you can use:

    • generate
    • edit
    • generate-batch