Mantishack (Mantis AI)

repository·main·Indexed 19 days ago

https://github.com/deonmenezes/mantishack

An autonomous vulnerability-discovery agent and offensive-AppSec harness that uses a staged detect-then-validate pipeline to find, verify, and attempt to fix software vulnerabilities via AI-driven attacker simulation.

Tokens
220.5K
Snippets
553
Records
1K
Agent score
65%

What's inside Mantishack

  1. Overview of codex-client

    main

    The codex-client crate provides a generic transport layer designed to handle HTTP requests, retries, and streaming primitives. It is intentionally agnostic of any specific Codex or OpenAI logic, making it a neutral utility for managing network communication.

    Key capabilities include:

    • HTTP Transport: Defines HttpTransport and a default ReqwestTransport implementation, along with lightweight Request and Response types.
    • Retry Utilities: Provides mechanisms for handling transient failures via RetryPolicy, RetryOn, run_with_retry, and backoff functions.
    • Streaming Support: Includes an sse_stream helper to convert byte streams into raw Server-Sent Events (SSE) data: frames, featuring idle timeouts and error surfacing.
  2. Overview of codex-app-server-daemon

    main

    The codex-app-server-daemon is an experimental component that manages the lifecycle of the codex app-server. It provides machine-readable commands used by remote clients (like desktop and mobile apps) to control Codex instances, particularly those launched over SSH. It is designed to expose the app-server with remote_control enabled for fresh developer machines.

    Platform Support: Currently Unix-only. It relies on Unix process and file-locking primitives and does not support Windows.

  3. 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 serves as a centralized location for host-facing tool models and helpers that are required by multiple consumers but should remain decoupled from the core orchestration logic.

    Key responsibilities include:

    • Aggregate Host Models: Managing types like ToolSpec, ConfiguredToolSpec, LoadableToolSpec, ResponsesApiNamespace, and ResponsesApiNamespaceTool.
    • Host Discovery: Providing models for discoverable tools and helpers for request-plugin-install during tool set assembly.
    • Host Adapters: Handling schema sanitization, MCP/dynamic conversion, code-mode augmentation, and image-detail normalization.
    • Executable-Tool Contracts: Defining shared interfaces such as ToolExecutor, ToolCall, and ToolOutput.
  4. Overview of codex-exec-server

    main

    codex-exec-server is a JSON-RPC server designed for spawning and controlling subprocesses using codex-utils-pty. It is used to manage remote or local execution environments.

    It provides three main interfaces:

    1. CLI entrypoint: codex exec-server for running the server.
    2. Rust client: ExecServerClient for programmatic control.
    3. Protocol module: Shared request/response types for JSON-RPC communication.

    The server handles transport, protocol, and filesystem/process management. Sandboxed filesystem operations are handled via a hidden helper dispatch in the top-level codex binary.

  5. What is argument-comment-lint?

    main

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

    It provides two specific lints:

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

    Exemptions:

    • String and char literals are exempt.
    • The sole non-self method argument is exempt if the method name matches the parameter name (e.g., .enabled(false) where the parameter is named enabled).
  6. What is codex_file_search?

    main

    codex_file_search is a fast fuzzy file search tool designed for Codex. It performs directory traversal while respecting ignore rules (like .gitignore) and provides fuzzy matching for user-supplied patterns.

    Key technical details:

    • Directory Traversal: Uses the ignore crate (the same engine used by ripgrep) to traverse directories while honoring .gitignore and other ignore files.
    • Fuzzy Matching: Uses the nucleo-matcher crate to match a user-supplied PATTERN against the discovered file list.
  7. Overview of codex-api

    main

    The codex-api crate provides typed clients for Codex/OpenAI APIs, built on top of the generic transport in codex-client. It serves as the wire-level layer consumed by codex-core.

    Key responsibilities include:

    • Hosting request/response models and request builders for Responses and Compact APIs.
    • Managing provider configuration (base URLs, headers, query params).
    • Handling auth header injection, retry tuning, and stream idle settings.
    • Parsing SSE streams into ResponseEvent/ResponseStream, including rate-limit snapshots and API-specific error mapping.
  8. Understand the Codex CLI Runtime for Python SDK

    main

    The openai-codex-cli-bin package serves as the platform-specific runtime for the published openai-codex Python SDK. It contains the necessary Codex CLI binaries required for the SDK to function.

    To ensure stability and avoid checking large platform binaries directly into the SDK repository, this package is staged during the release process, allowing the SDK to pin an exact version of the Codex CLI.

  9. Use the openai-docs skill for OpenAI guidance

    main

    The openai-docs skill provides authoritative guidance for building with OpenAI products and APIs. Use this skill when you need:

    • Up-to-date official documentation with citations.
    • Help choosing the latest model for a specific use case.
    • Guidance on model upgrades or prompt upgrades.
    • Information about Codex surfaces or Codex self-knowledge.

    Note on API Keys: For tasks involving building, running, configuring, or debugging API-backed applications, ensure the openai-platform-api-key is resolved first before proceeding with documentation lookups.

  10. Classify commands with codex-execpolicy-legacy

    main

    The codex-execpolicy-legacy crate classifies proposed execv(3) commands into one of four states to determine their safety. Instead of a simple boolean, it returns a structured result so callers can make informed decisions based on file access requirements.

    Classification States:

    • safe: The command is considered safe to run.
    • match: The command matched a rule, but the caller must decide safety based on the files the command will write (e.g., commands involving WriteableFile).
    • forbidden: The command is explicitly disallowed by a policy rule.
    • unverified: Safety cannot be determined; manual user intervention is required.

    Note on Safety: A safe classification does not guarantee the command will succeed (e.g., a file might not exist), only that the command does not violate the defined security policy.

    # Example: Checking the command 'ls -l foo'
    cargo run -p codex-execpolicy-legacy -- check ls -l foo | jq
  11. Use codex-utils-template for strict string templating

    main

    The codex-utils-template library provides a small, strict templating engine designed for prompt and text assets. It supports placeholder interpolation and literal brace escaping.

    Supported Syntax

    • {{ name }}: Interpolates the value associated with name.
    • {{{{: Renders a literal {{.
    • }}}}: Renders a literal }}.

    Strictness Guarantees

    The library is designed to fail early and explicitly in the following scenarios:

    • Parsing: Fails if placeholders are malformed.
    • Rendering (Missing): Fails if a placeholder in the template has no corresponding value.
    • Rendering (Duplicate): Fails if a value is provided more than once.
    • Rendering (Extra): Fails if values are provided that are not used by the template.
    use codex_utils_template::Template;
    use codex_utils_template::render;
    
    // Using the Template struct
    let template = Template::parse(
        "Hello, {{ name }}.\nLiteral braces: {{{{ and }}}}.\nMode: {{ mode }}",
    )?;
    
    let rendered = template.render([
        ("name", "Codex"),
        ("mode", "strict"),
    ])?;
    
    // Using the one-shot render function
    let one_shot = render("Hi {{ who }}!", [("who", "there")])?;