CodeCortex Context Engine

---

为什么选择 CodeCortex？

编码 Agent 可以阅读代码。更难的问题是判断哪些内容重要、哪些内容彼此关联、什么可能出问题，以及实际值得向模型提供多少上下文。

CodeCortex 将代码库转化为面向编码 Agent 的、针对查询的证据系统：

• 代码库与符号智能 — 结构、定义、引用、依赖关系和调用关系。
• 注重证据的检索 — 综合排序词法、语义、结构、图、Git、架构和记忆信号。
• 编辑前评估影响 — 修改前可检查反向依赖、受影响的测试、代码所有权和变更风险。
• 受控变更 — 语义编辑和结构化重写预览明确保留源代码边界和审查步骤。
• 持久化项目上下文 — 架构、历史、项目／团队记忆、跟踪记录和多代码库工作区不会因一次聊天结束而消失。

核心规则：先检索证据，再生成信心。

60 秒快速开始

需要 Python 3.11–3.13。

python -m pip install --upgrade codecortex-context-engine
cortex init .
cortex index
cortex doctor

接着向代码库提出有用的问题：

cortex architecture
cortex semantic "authentication and session lifecycle"
cortex impact AuthService

或者将代码库提供给支持 MCP 的编码 Agent：

cortex mcp --path .

适用于编码 Agent

CodeCortex 包含可安全合并的项目配置，支持 Claude Code、Codex、Cursor、Gemini CLI 和 OpenCode。

cortex agents detect
cortex agents configure --dry-run
# or configure every supported target explicitly:
cortex agents configure --all

配置工具仅管理由 CodeCortex 管理的 MCP 条目，并会保留用户自行管理的配置。

在本地查看运行效果

代码库附带一个确定性演示项目和演示运行器：

python scripts/demo.py

演示会为 fixture 代码库建立索引，分析 AuthService 的影响范围，路由证据请求，并报告实测的上下文／跟踪数据。它不会捏造基准测试数值。

可复现的证据快照

这些是已提交的加固测量结果，并非普遍适用的性能承诺：

证据	记录结果
加固测试套件	711 项通过，28 项跳过，0 项失败
加固报告中的覆盖率	91.74%
热缓存下的精确定义查找	中位数 0.19–0.23 ms
扫描 600 个文档的新鲜度	中位数 4.25 ms

有关范围、方法、局限性和可复现性说明，请参阅 HARDENING_REPORT.md 和 benchmarks/。

❤️ 支持 CodeCortex — 如果 CodeCortex 为你节省了时间，不妨支持它持续进行开源开发。加密货币支持 →

---

🇬🇧 英语

一句话了解 CodeCortex

CodeCortex 将软件代码库转化为面向 AI 编码 Agent 的任务专属证据系统。

它位于 Agent 与代码库之间，构建关于代码库结构、符号、关系、Git 历史、所有权、架构、团队决策、影响和验证的持久化智能。对于每项任务，它都会尽力返回最精简且有用的证据包，而不是让模型重新打开代码库的大部分内容，再次重建相同的事实。

CodeCortex 并非又一个通用聊天界面，也不是模型提供商。它不声称 Agent 能变得万无一失。它是上下文基础设施：一个能改善 Agent 可用于推理的信息的层。

核心规则：先检索证据，再生成信心。

---

为什么要做这个项目

强大的编码模型能够阅读代码。更难的工程问题在于判断哪些内容值得关注、哪些内容与之相关、发生了哪些变化、哪些地方存在歧义、谁负责相关区域，以及变更后可能会破坏什么。

没有上下文引擎时，工作流程通常是这样的：

搜索文件名
→ 打开大范围文件
→ 重新发现架构
→ 猜测符号归属
→ 推断引用关系
→ 手动检查 Git
→ 猜测影响范围
→ 消耗大量上下文窗口
→ 编辑
→ 之后才发现隐藏依赖

CodeCortex 改变了这一流程：

任务
→ 分类意图
→ 收集代码库证据
→ 针对当前任务排列证据优先级
→ 保留来源信息和不确定性
→ 将证据控制在上下文预算内
→ 提供一个面向 Agent 的入口
→ 验证拟议的变更

目标不是提供更多上下文。

目标是提高每个 Token 所承载的证据价值。

---

架构

实时证据流

flowchart LR
    A[AI Coding Agent] --> G[CodeCortex Gateway]
    G --> R[Adaptive Router]

    R --> REP[Repository Intelligence]
    R --> SYM[Symbol Intelligence]
    R --> RET[Hybrid Retrieval]
    R --> GIT[Git + PR Intelligence]
    R --> MEM[Project + Team Memory]
    R --> ARC[Architecture + Drift]
    R --> IMP[Impact + Validation]

    REP --> E[Evidence Surface]
    SYM --> E
    RET --> E
    GIT --> E
    MEM --> E
    ARC --> E
    IMP --> E

    E --> C[Context Pipeline]
    C --> B[Rank + Dedup + Slice + Budget]
    B --> G
    G --> A

代码库仍然是可执行事实的来源。图谱、记忆、语义检索、架构推断和摘要有助于解读信息，但不能替代当前的源代码、配置和测试。

---

当前能力图谱

层级	功能	重要性
仓库图谱	为结构和文件建立索引	为 Agent 提供边界明确的图谱
多语言符号	提取具备语言感知能力的单元	超越按文件名搜索
树感知解析	保留结构化代码单元	改善代码级上下文
依赖关系 + 调用图	记录关系	支持导航和影响分析
跨文件解析	为含糊的目标排序	让不确定性清晰可见
增量图谱	对变更状态重新解析	避免盲目重建
混合检索	结合词法、语义和结构信号	提高针对具体任务的召回率
上下文流水线	排序、去重、切片、预算分配、压缩	将 Token 用在有用的证据上
Git 智能分析	历史记录、归属信息、变更频率、所有权	让变更历史可供查询
PR 智能分析	将差异映射到符号、测试、影响和风险	审查行为，而不只是代码行
影响分析	沿反向关系遍历	估算影响范围
架构推断	以置信度推断可观测结构	让架构可供检查
架构漂移	将结构与基线进行比较	揭示架构变化
项目记忆	存储持久的决策和事实	保留决策依据
团队共享记忆	版本修订 + 感知冲突的共享状态	让团队知识持久留存
多仓库工作区	聚合搜索结果和图谱证据	支持由多个仓库组成的系统
任务轨迹	记录范围明确的执行证据	让路由行为可供检查
有守护的语义编辑	执行具备预检能力的编辑	减少范围过广且不安全的替换
原生 MCP	提供稳定统一的 Agent 接口	与编码 Agent 集成
远程 MCP	经过身份验证的远程操作	支持受控的共享使用
持久化向量提供方	将存储与检索接口分离	支持更大规模的部署
分布式工作器	能力 + 租约 + 重试	明确呈现节点故障
观测中心	健康状况、轨迹、漂移、图谱、基准测试、PR 信号	让引擎可观测
精准代码智能	根据符号身份解析定义和引用	区分导出同名内容的不同包
依赖智能	将声明的约束与解析出的版本分开	确定仓库实际运行的是哪个 API
结构化搜索与重写	匹配语法，预览有守护的迁移	查找调用，而不是提及它们的注释
平台 API 和控制台	HTTP 接口、任务、持久化、实时事件	从 CLI 外部驱动 CodeCortex
Python 和 TypeScript SDK	平台 API 的类型化客户端	将 CodeCortex 嵌入其他工具
发布证据	扫描、SBOM、签名、来源证明	将发布声明与制品关联

---

CodeCortex 准则

这些是工程规则，而不是营销口号。

准则 01 — 证据优先于置信度

已解析的符号、语义匹配、推断出的边、记忆条目和 Git 观测属于不同的证据类别。CodeCortex 不应将它们一概视为同等确定。

精确证据       → 标记为精确
强推断         → 保留来源信息
含糊的推断     → 保留其他可能性，清晰呈现
缺失的证据     → 报告缺失
过时的证据     → 报告过时

准则 02 — 最小但够用的上下文

最好的上下文包不是容量允许范围内最大的包，而是包含足够源代码、关系、历史记录和验证证据，能够对当前任务进行推理的最小包。

准则 03 — 源代码仍是源代码

记忆可以解释意图。Git 可以解释历史记录。图谱可以解释关系。检索可以提示相关性。对于可执行行为，当前源代码、配置、测试和可复现的制品仍具有权威性。

原则 04 — 不确定性也是信息

如果两个符号都可能是目标，那么这种歧义很重要。如果架构是推断出来的，那么缺失的信号也很重要。如果可选集成无法运行，那么“不可用”比捏造成功更有用。

原则 05 — 每项变更都有影响范围

小型差异也可能风险很高。大型差异也可能只是机械性修改。值得关注的问题是：哪些符号发生了变化，哪些组件依赖它们，哪些测试会覆盖它们，谁负责该领域，以及有哪些证据支持这一风险评估。

原则 06 — 本地优先是一项信任决策

核心仓库分析在本地运行。任何网络边界、凭据、远程工具、配额、策略和数据传输都必须保持明确。

原则 07 — 可复现性胜过亮眼数字

如果一项基准测试声明没有可复现的规范、固定的修订版本、环境、测量结果和产物，就不能算作有力证据。

原则 08 — 通过明确协调实现规模化

工作者具有身份、能力、租约、故障、重试和状态。共享内存具有同步和冲突处理机制。远程工具具有身份验证和策略。

---

快速开始

安装

CodeCortex 支持 Python 3.11、3.12 和 3.13。

python -m pip install --upgrade codecortex-context-engine

可选的解析器支持：

python -m pip install "codecortex-context-engine[parsers]"

可选的本地神经语义嵌入：

python -m pip install "codecortex-context-engine[semantic]"

在仓库中启动

cortex init .
cortex index
cortex doctor

cortex architecture
cortex semantic "authentication and session lifecycle"
cortex impact AuthService
cortex symbol-history src/auth.py 10 80

cortex mcp --path .

---

30 秒了解其工作原理

          ┌────────────────────────────┐
          │       编码 Agent            │
          └─────────────┬──────────────┘
                        │ 任务
          ┌─────────────▼──────────────┐
          │        CodeCortex          │
          │ 映射 · 符号 · 历史         │
          │ 图 · 检索 · 记忆           │
          │ 影响 · 架构                │
          │ 验证 · 策略                │
          └─────────────┬──────────────┘
                        │ 有界证据
          ┌─────────────▼──────────────┐
          │       编码 Agent            │
          │ 借助更完善的映射进行推理     │
          └────────────────────────────┘

Agent 仍然负责推理。CodeCortex 改变的是它进行推理时所依据的内容。

---

任务流

Bug 调查

sequenceDiagram
    participant A as Agent
    participant C as CodeCortex
    participant R as Repository
    participant G as Graph
    participant H as Git/History
    participant V as Validation

    A->>C: Trace a failing behavior
    C->>R: locate source and symbols
    C->>G: resolve callers and dependencies
    C->>H: inspect recent change and ownership
    C->>V: identify tests and validation signals
    C-->>A: compact evidence package + impact

有用的调查应回答：

1. 该行为在哪里实现？
2. 哪些调用方和引用参与其中？
3. 最近发生了哪些变化？
4. 哪条替代路径可能推翻这一假设？
5. 如果解释有误，哪个测试会失败？
6. 最小且安全的变更是什么？

Pull Request 审查

差异
→ 变更文件
→ 变更符号
→ 下游影响
→ 受影响的测试
→ 变更频率 / 归属
→ 架构变动
→ 风险证据
→ 审查上下文

PR 规模只是一个信号。

多仓库工作

前端仓库 ───────┐
后端仓库 ───────┼── 联邦证据 ──→ 任务上下文
契约仓库 ───────┘

各仓库保留自己的身份。CodeCortex 联合证据，而不是假装它们属于同一个物理代码库。

---

智能能力

仓库智能 — 先了解结构，再做推测

增量索引会将文件和程序单元转化为持久的仓库状态。检索、架构推断、影响分析和 MCP 工具可以复用这些状态，而不必在每次请求时重新探索整个仓库。

符号智能 — 名称、容器、签名、引用

语言感知解析会提取程序单元，并尽可能保留容器标识。跨文件解析会有意保留歧义和候选项理由，而不是悄悄选择一个同名符号。

混合检索 — 词法 + 语义 + 结构

代码不是普通散文。CodeCortex 会结合词法证据、语义相似度、符号元数据和结构上下文。上下文切片优先选择有意义的结构单元和有界窗口，而不是不受控制地转储整个文件。

Git 与 PR 智能 — 代码有历史

当前源代码说明代码现在的行为。Git 则说明代码如何演变至此。历史、归属信息、所有权、变更频率和 PR 分析会为静态代码模型补充变更证据。

记忆 — 持久化理由，而非替代事实

项目记忆用于存储可复用的事实和决策。团队记忆则增加了修订、参与者/来源元数据、乐观并发和冲突处理。记忆可以解释“为什么”，但当前源代码和测试仍具有权威性。

架构智能 — 让结构变化清晰可见

架构推断会返回证据和置信度。将保存的指纹与当前图进行比较后，新的依赖方向、耦合增长和结构漂移便可供检查。

影响与验证 — 分析影响范围

影响分析会沿反向关系追踪，并查找受影响的测试。验证会根据仓库证据检验拟议变更。只有当其背后的证据清晰可见时，风险评分才有用。

---

有保障的编辑

当前语义编辑操作包括：

cortex edit rename src/auth.py AuthService SessionService
cortex edit replace src/auth.py AuthService/refresh --body-file ./replacement.txt
cortex edit insert-before src/auth.py AuthService --body-file ./imports.txt
cortex edit insert-after src/auth.py AuthService --body-file ./helper.txt

预期的变更流程是：

充分阅读以理解内容
→ 评估影响
→ 精准修改
→ 验证

而不是：

到处替换文本
→ 寄希望于测试能发现问题

---

MCP：面向 Agent 的统一界面

cortex mcp --path /path/to/repository

MCP 界面提供仓库映射、符号搜索、引用、依赖图检查、影响分析、混合检索、精简上下文、架构智能、Git 历史、PR 智能、记忆、工作区搜索、追踪、验证和统计功能。

类别	Agent 可请求的内容
仓库	映射、匹配节点、图计数
符号	程序单元和位置
引用	目标周围的关系
依赖	本地调用/导入关系
影响	直接、间接影响及受影响测试的证据
检索	语义/词法/结构匹配结果
上下文	在明确预算内提供精简证据
架构	推断的结构和漂移
历史	Git 历史、归属信息、所有权
拉取请求	变更的符号、影响、测试、风险
记忆	项目和团队知识
工作区	多仓库搜索
追踪	执行摘要
验证	验证证据
统计	仓库、图、Git、运行时状态

---

分布式运行

flowchart TB
    AG[AI Agents] --> GW[Remote MCP Gateway]
    GW --> AUTH[Authentication]
    AUTH --> POL[Tool Policy + Quotas]
    POL --> COORD[Coordinator]

    COORD --> IDX[Index Workers]
    COORD --> RET[Retrieval Workers]
    COORD --> CTX[Context Workers]

    IDX --> GRAPH[(Graph State)]
    RET --> VEC[(Persistent Vector Store)]
    CTX --> MEM[(Synchronized Team Memory)]

    COORD --> AUDIT[(Audit + Performance History)]

工作者会公布自身能力。工作会以租约方式分配。过期的工作可以重新排队。远程运行会增加身份验证、TLS 支持、配额、工具策略、组织／工作区策略和审计凭证。

仪表板是可观测性界面，不是授权边界。

---

Observatory

cortex dashboard -p /path/to/repository

本地 Observatory 可以呈现：

后端健康状况
路由分布
上下文使用情况
引擎延迟
图谱热点
任务追踪
架构偏移
基准测试历史
拉取请求风险

上下文引擎应能够解释自身的路由决策、证据来源和故障状态。

---

安全模型

边界	控制方向
源代码路径	将操作限制在项目根目录内
语义编辑	预检 + 有界路径处理
任务追踪	有界属性 + 脱敏
可选后端	进程隔离
远程 MCP	分发前进行身份验证
远程工具	策略 + 允许列表 + 配额
组织	角色 + 工作区策略 + 审计留存
依赖项	审计 + 依赖项审查
源代码	静态分析 + CodeQL
发布	校验和 + SBOM + 签名 + 来源证明

安全徽章是证据，并不能证明每种部署都安全。针对具体部署的威胁模型仍然很重要。

---

质量、发布与基准测试准则

精确提交
→ 质量矩阵
→ 安全检查
→ 构建
→ 冒烟测试
→ 校验和
→ SBOM
→ 签名／证明
→ 发布

无法运行的凭据门控集成会报告为已跳过，而不计为成功。

基准测试命令：

python scripts/run_production_benchmark.py

公开的性能声明应对应可复现的规范、固定版本、环境、测量结果和产物。CodeCortex 不会捏造令牌节省量、速度提升、任务成功率提升或准确率百分比。

---

Evidence Fusion Layer

状态：已交付。 实现、测试、基准测试、文档和来源记录均位于代码仓库中。所有三个层都是可选的：即使未安装其中任何一层且无法访问网络，CodeCortex Core 仍可运行。

CodeCortex 融合多种证据，并针对每个结果告诉 Agent，该结果是如何得出的。每条记录都带有一个分类信任等级——exact、near_exact、structural、inferred_high、inferred、weak——以及来源标签。代码强制执行两项属性，而不只是写在文档中：除非证据是最新的，否则不能标为 exact；过时的精确证据绝不会胜过最新的结构证据。

完整模型、回退行为和安全边界请参阅 docs/EVIDENCE_FUSION.md。

1 — 精确代码智能

精确代码智能层会在可用时使用编译器／索引器级别的出现位置证据，并区分：

精确的定义／引用
        与
结构关系
        与
启发式候选项
        与
词法巧合

当前功能：

• 精确定义查找；
• 精确引用；
• 实现关系；
• 符号出现位置；
• 过时索引检测；
• 带有精确／推断来源信息的图融合；
• 平稳回退到当前智能功能。

flowchart TB
    EX[Exact index/compiler evidence] --> F[Evidence Fusion]
    SEM[Language-aware semantic evidence] --> F
    AST[AST / structural evidence] --> F
    GR[Graph inference] --> F
    HEU[Heuristic resolution] --> F
    LEX[Lexical match] --> F
    F --> CTX[Task-ranked context]

引擎不仅应知道自己找到了什么，还应知道自己对此有多大把握。

2 — 版本感知依赖智能

依赖智能层整合：

清单文件
+ 锁定文件
+ 声明的版本
+ 解析出的版本
+ 仓库用法
+ 与版本相关的文档证据

此层可回答以下问题：

• 实际解析出的版本是什么？
• 请求的 API 对该版本是否有效？
• 当前模式是否已过时？
• 哪些迁移指南适用？
• 哪些本地文件和符号使用了该依赖？

外部文档仍保持可选、数据最少、凭证感知、经过缓存且明确。核心仓库智能必须继续支持离线运行。默认情况下，不应仅为了回答依赖问题就将仓库源代码发送到系统外部。

3 — 结构化搜索与受控重写

结构化搜索与受控重写层负责处理语法感知模式：

查找形如 old_api($X) 的调用
查找使用旧版选项结构的构造函数
查找吞掉特定异常形式的处理程序
查找框架迁移前的所有结构化用法

变更生命周期：

flowchart LR
    Q[Migration request] --> S[Structural search]
    S --> M[Match set]
    M --> I[Impact analysis]
    I --> P[Rewrite preview]
    P --> A{Mutation allowed?}
    A -- No --> STOP[Preview only]
    A -- Yes --> W[Bounded rewrite]
    W --> R[Reindex]
    R --> V[Validation]
    V --> POST[Post-change impact]

重写应先预览，限定范围，检查内容哈希，经策略授权，重新建立索引并验证。

实际应用中的证据融合

示例，通过端到端验收测试覆盖：

将身份验证中间件迁移到此仓库所用版本支持的 API。

流程：

依赖清单
→ 解析出的版本
→ 当前中间件
→ 精确引用
→ 与版本相关的文档
→ 结构化出现位置
→ 受影响的符号和测试
→ 受控重写预览
→ 变更策略
→ 验证
→ 变更后的影响

价值不在于三个彼此独立的工具。价值在于一个上下文引擎，它能针对一项任务，将本地代码事实、精确关系、依赖版本证据、结构化模式、历史记录和验证整合起来。

在测试仓库上测得（cortex evidence-benchmark；无法测量的策略会标记为跳过，绝不估算）：

情况	启发式基线	有证据支持
重名符号	精确率 0.50	精确率 1.00
已解析的依赖版本	精确率 0.00	精确率 1.00
机械式迁移	精确率 0.50	精确率 1.00

---

已提供的功能与回退行为

功能	已提供	可选层缺失时的回退方式
符号	语言感知解析 + 精确出现位置融合	结构化解析和启发式解析
引用	精确／推断的来源层级	图谱 + 语义智能
依赖	已解析版本 + 可选文档证据	本地清单事实，明确标记文档不可用状态
搜索	词法 + 语义 + 结构化 + AST 模式搜索	词法和符号搜索
编辑	受控语义编辑 + 预览优先的结构化迁移	仅受控语义编辑
影响	感知证据质量的影响分析	图遍历 + 受影响的测试
上下文	统一的跨提供方证据排序	排序、去重并控制预算的代码块
置信度	来源 + 信任等级	明确标示歧义
离线行为	本地优先	保持不变；绝不要求联网

---

运行配置

配置	典型形态
个人	本地仓库 → 本地索引 → 本地记忆 → MCP Agent
团队	共享约定 → 团队记忆 → 工作区 → PR 智能
大型工作区	多个仓库 → 联邦式证据 → 远程身份验证接口
分布式	网关 → 策略 → 协调器 → 工作器 → 持久化存储

CodeCortex 不是什么

它不是什么	原因
通用聊天应用	它的职责是提供代码仓库上下文智能
模型提供商	它能改善模型可用的证据
神奇的正确性保障层	模型和人类仍然可能出错
测试的替代品	验证需要可执行的证据
Git 的替代品	它让历史记录对上下文更有用
向量数据库产品	存储是可替换的边界
源码真相的替代品	源码仍然具有权威性
基准测试营销页面	声明需要可复现的产物

---

设计规则

1. 类型化边界。
2. 智能能力可替换。
3. 优先本地运行。
4. 明确上下文预算。
5. 默认使用项目范围内的状态。
6. 汇总后仍保留来源信息。
7. 变更操作需要单独授权。
8. 明确分布式状态。
9. 缺失的证据仍应标记为缺失。
10. 发布声明应有对应证据。

---

命令一览

cortex init .
cortex index
cortex architecture
cortex architecture-drift
cortex semantic "authentication refresh"
cortex impact AuthService
cortex symbol-history src/auth.py 10 80
cortex pr main --head HEAD
cortex workspace-add backend ../backend
cortex workspace-search "payment service"
cortex definition src/auth.py 12 7
cortex references src/auth.py 12 7
cortex implementations src/auth.py 12 7
cortex precision-status
cortex dependency next
cortex dependency-docs next "middleware authentication"
cortex structural-search --lang python --pattern 'old_api($X)'
cortex rewrite-preview --lang python --pattern 'old_api($X)' --replacement 'new_api($X)'
cortex rewrite-apply <preview-id>
cortex benchmark
cortex evidence-benchmark
cortex dashboard
cortex doctor
cortex mcp --path .

---

Docker

docker build --target core -t codecortex:core .
docker build --target full -t codecortex:full .
docker compose up dashboard

容器化不能替代身份验证、TLS、策略、密钥管理或适当的部署威胁模型。

---

项目状态

CodeCortex 目前处于Alpha 阶段。

公共接口仍在演进。在 1.0 版本发布前可能会发生破坏性变更。请根据当前代码、测试、CI、文档和可复现产物所展示的内容来评估项目。

---

工程应用场景

目标	从这里开始	通过以下内容验证
新人上手	架构 + 代码仓库地图	源码 + 执行路径
Bug 调查	语义 + 符号 + 历史记录	定向测试
功能开发	现有模式 + 依赖项	架构 + 测试
重构	引用 + 影响分析	暂存的编辑 + 契约测试
依赖迁移	导入 + 用法 + 假设	兼容性检查
安全审查	信任边界 + 调用路径	负向测试／对抗性测试
PR 审查	已变更符号 + 影响分析	受影响的测试 + 架构偏差
发布就绪度	CI + 安全 + 基准测试证据	确切的发布产物

---

社区

适合新手的议题 · 报告 Bug · 贡献指南

文档

• 架构
• 分布式运行
• 高级智能
• 证据融合
• 集成
• 质量
• 测试
• 发布
• 许可
• 安全
• 贡献
• 治理
• 路线图
• 云端与企业版提前体验

---

常见问题

CodeCortex 会取代编码模型吗？

不会。模型仍然负责推理和生成。CodeCortex 改善的是证据环境。

Core 需要远程服务吗？

不需要。Core 以本地优先。可选的提供方可能会引入明确的远程边界。

超大的上下文窗口会让它变得多余吗？

不会。窗口大小和证据质量是两个不同的问题。

每种关系都是精确的吗？

不是。推断出的关系会保留歧义。Precision Code Intelligence 会在可用时添加精确的编译器／索引器证据；不可用时则采取保守回退。

它能跨仓库工作吗？

可以。工作区会联合证据，同时保留仓库身份。

它能编辑代码吗？

可通过相应的后端接口进行受保护的语义编辑。读取智能与修改仍是分开的权限。

---

维护者、贡献与许可证

CodeCortex 由 Behnam Jalali 构建并维护。

python -m pip install -e ".[dev]"
ruff check .
mypy src/codecortex
pytest

CodeCortex 自有材料采用 Apache License 2.0 许可。第三方材料仍受仓库中记录的许可证和署名要求约束。

请参阅 LICENSE、NOTICE、SECURITY.md 和 CONTRIBUTING.md。

---

## چرا اصلاً به چنین چیزی نیاز داریم؟

مدل قوی می‌تواند کد بخواند. مسئله سخت مهندسی این است که بداند کدام کد ارزش توجه دارد، چه چیزی به آن وصل است، چه چیزی عوض شده، کجا ambiguity داریم، مالک آن بخش کیست و اگر تغییر اشتباه باشد چه چیزی می‌شکند.

بدون موتور کانتکست، جریان معمولاً این شکلی می‌شود:

جست‌وجوی اسم فایل
→ باز کردن فایل‌های زیاد
→ کشف دوباره معماری
→ حدس زدن مالکیت سیمبل
→ حدس referenceها
→ بررسی دستی Git
→ حدس blast radius
→ مصرف کانتکست زیاد
→ ویرایش
→ کشف یک dependency پنهان در مرحله بعد

CodeCortex جریان را عوض می‌کند:

تسک
→ تشخیص intent
→ جمع‌آوری evidence ریپو
→ rank کردن برای همین تسک
→ حفظ provenance و uncertainty
→ جا دادن evidence داخل context budget
→ ارائه از یک سطح واحد به ایجنت
→ validation تغییر پیشنهادی

هدف کانتکست بیشتر نیست.

هدف evidence مفیدتر به ازای هر توکن است.

---

معماری سیستم

استریم زنده Evidence

flowchart LR
    A[AI Coding Agent] --> G[CodeCortex Gateway]
    G --> R[Adaptive Router]

    R --> REP[Repository Intelligence]
    R --> SYM[Symbol Intelligence]
    R --> RET[Hybrid Retrieval]
    R --> GIT[Git + PR Intelligence]
    R --> MEM[Project + Team Memory]
    R --> ARC[Architecture + Drift]
    R --> IMP[Impact + Validation]

    REP --> E[Evidence Surface]
    SYM --> E
    RET --> E
    GIT --> E
    MEM --> E
    ARC --> E
    IMP --> E

    E --> C[Context Pipeline]
    C --> B[Rank + Dedup + Slice + Budget]
    B --> G
    G --> A

حقیقت اجرایی همچنان سورس فعلی، کانفیگ و تست است. Graph، memory، semantic retrieval، architecture inference و summary برای فهم بهتر هستند؛ جای source truth را نمی‌گیرند.

---

نقشه قابلیت‌های فعلی

لایه	چه کاری می‌کند	چرا مهم است
Repository map	ساختار و فایل‌ها را index می‌کند	به ایجنت نقشه محدود می‌دهد
سیمبل چندزبانه	program unit زبان‌آگاه استخراج می‌کند	از filename search جلوتر می‌رود
Tree-aware parsing	ساختار کد را حفظ می‌کند	context کدنویسی بهتر می‌شود
Dependency + call graph	رابطه کد را ثبت می‌کند	navigation و impact ممکن می‌شود
Cross-file resolution	target مبهم را rank می‌کند	uncertainty پنهان نمی‌شود
Incremental graph	فقط state تغییرکرده را parse می‌کند	rebuild کور کم می‌شود
Hybrid retrieval	lexical + semantic + structural	recall مربوط به تسک بهتر می‌شود
Context pipeline	rank + dedup + slice + budget + compact	توکن صرف evidence مفید می‌شود
Git intelligence	history + blame + churn + ownership	تغییرات queryable می‌شوند
PR intelligence	diff را به symbol + test + impact + risk وصل می‌کند	review رفتاری می‌شود
Impact analysis	reverse relationship را دنبال می‌کند	blast radius دیده می‌شود
Architecture inference	ساختار را با confidence می‌فهمد	معماری inspectable می‌شود
Architecture drift	current را با baseline مقایسه می‌کند	حرکت معماری دیده می‌شود
Project memory	fact و تصمیم ماندگار	rationale حفظ می‌شود
Shared team memory	revision + conflict-aware state	دانش تیم ماندگار می‌شود
Multi-repo workspace	search و graph را federate می‌کند	سیستم چندریپویی قابل فهم می‌شود
Task trace	execution evidence محدود	رفتار routing inspectable می‌شود
Guarded semantic editing	edit با preflight	replace ناامن کمتر می‌شود
Native MCP	یک سطح پایدار برای ایجنت	integration ساده‌تر می‌شود
Remote MCP	عملیات authenticated ریموت	استفاده اشتراکی کنترل می‌شود
Persistent vector providers	storage از contract retrieval جداست	deployment بزرگ‌تر scale می‌شود
Distributed workers	capability + lease + retry	failure نود واقعی مدل می‌شود
Observatory	health + trace + drift + graph + benchmark	خود engine observable می‌شود
Precision code intelligence	تعریف و ارجاع را با هویت سیمبل resolve می‌کند	پکیج‌هایی که نام یکسان export می‌کنند از هم جدا می‌شوند
Dependency intelligence	constraint اعلام‌شده را از نسخه resolve‌شده جدا می‌کند	مشخص می‌کند ریپو واقعاً کدام API را اجرا می‌کند
Structural search و rewrite	بر اساس syntax تطبیق می‌دهد و migration کنترل‌شده preview می‌کند	فراخوانی واقعی را پیدا می‌کند، نه کامنتی که اسمش را آورده
Platform API و کنسول	سطح HTTP، job، persistence و رویداد زنده	اجرای CodeCortex از بیرون CLI
SDK پایتون و TypeScript	کلاینت تایپ‌دار برای Platform API	جاسازی CodeCortex در ابزارهای دیگر
Release evidence	scan + SBOM + signature + provenance	claim به artifact وصل می‌شود

---

دکترین CodeCortex

این‌ها slogan نیستند؛ قانون مهندسی‌اند.

原则 ۰۱ — 先看 evidence，再谈 confidence

已解析的 symbol、semantic match、推断出的 edge、memory 和 Git observation 的质量并不相同。CodeCortex 不应把它们都当作具有相同 certainty 的内容提供。

精确证据          → 精确呈现
强推断            → 保留 provenance
模糊推断          → 保留其他选项
没有证据          → 报告 missing
证据过时          → 报告 stale

原则 ۰۲ — 只提供足够的最小上下文

最佳 context package 不是能装下的最大内容，而是针对当前 task，包含足够的源码、关系、历史记录和验证信息的最小 package。

原则 ۰۳ — Source 仍然是 Source

Memory 可以解释原因。Git 提供历史记录。Graph 展示关系。Retrieval 提供可能的关联。但运行时行为由当前源码、配置、测试和可复现的 artifact 决定。

原则 ۰۴ — 模糊性本身就是信息

如果有两个可能的 target symbol，这种 ambiguity 很重要。如果架构是推断出来的，missing signal 很重要。如果无法使用可选的 integration，报告 unavailable 总比伪造 success 好。

原则 ۰۵ — 每次变更都有 Blast Radius

小型 diff 可能风险很高，大型 diff 也可能只是机械改动。正确的问题是：哪些 symbol 发生了变化、哪些内容依赖它们、哪些测试覆盖了这条路径、谁负责该部分，以及 risk 基于什么 evidence。

原则 ۰۶ — Local-first 是一项信任决策

核心智能在本地运行。每个 network boundary、credential、远程工具、quota、policy 和 data transfer 都必须明确说明。

原则 ۰۷ — 可复现性比吸引人的数字更重要

没有 spec、revision、environment、测量输出和 artifact evidence 的 benchmark 并不可靠。

原则 ۰۸ — 通过明确的 Coordination 实现 Scale

Worker 具有 identity、capability、lease、failure、retry 和 state。Shared memory 涉及 sync 和 conflict。远程工具涉及 auth 和 policy。

---

快速开始

安装

CodeCortex 支持 Python 3.11、3.12 和 3.13。

python -m pip install --upgrade codecortex-context-engine

可选 Parser：

python -m pip install "codecortex-context-engine[parsers]"

可选的本地语义 Embedding：

python -m pip install "codecortex-context-engine[semantic]"

在仓库中开始使用

cortex init .
cortex index
cortex doctor

cortex architecture
cortex semantic "authentication and session lifecycle"
cortex impact AuthService
cortex symbol-history src/auth.py 10 80

cortex mcp --path .

---

30 秒理解心智模型

          ┌────────────────────────────┐
          │       编码 Agent         │
          └─────────────┬──────────────┘
                        │ task
          ┌─────────────▼──────────────┐
          │        CodeCortex          │
          │ map · symbols · history    │
          │ graph · retrieval · memory │
          │ impact · architecture      │
          │ validation · policy        │
          └─────────────┬──────────────┘
                        │ 有限的 evidence
          ┌─────────────▼──────────────┐
          │       编码 Agent         │
          │  借助更完善的地图进行 reasoning │
          └────────────────────────────┘

Agent 仍然自行进行 reasoning。CodeCortex 改进的是 Agent 用来进行 reasoning 的内容。

---

Task 流程

Bug 调查

sequenceDiagram
    participant A as Agent
    participant C as CodeCortex
    participant R as Repository
    participant G as Graph
    participant H as Git/History
    participant V as Validation

    A->>C: Trace a failing behavior
    C->>R: locate source and symbols
    C->>G: resolve callers and dependencies
    C->>H: inspect recent change and ownership
    C->>V: identify tests and validation signals
    C-->>A: compact evidence package + impact

良好的调查应回答：

1. 行为在哪里实现？
2. 路径上有哪些 caller 和 reference？
3. 最近有哪些变更？
4. 哪条不同的路径可以推翻这个 hypothesis？
5. 如果解释有误，哪个 test 应该 fail？
6. 最小的安全变更是什么？

Pull Request Review

diff
→ 变更的文件
→ 变更的 symbol
→ 下游影响
→ 受影响的测试
→ churn / ownership
→ 架构变化
→ risk evidence
→ review 上下文

PR 大小只是其中一个 signal。

多仓库

frontend repo ───────┐
backend repo ────────┼── 联合 evidence ──→ task 上下文
contracts repo ──────┘

保留各仓库的 identity。联合 evidence，而不是假装它们属于同一个物理 codebase。

---

智能层级

仓库智能 — 先查看结构，不要猜测

增量索引会将文件和程序单元转化为持久状态。检索、架构、影响分析和 MCP 可以重复使用同一状态。

符号智能 — 名称、容器、签名和引用

语言感知解析会提取程序单元。跨文件解析会保留歧义和候选项的理由，不会悄悄将同名符号视为同一个符号。

混合检索 — 词法 + 语义 + 结构

代码不是普通文本。CodeCortex 将语义相似度与词法证据、符号元数据和结构上下文结合起来，并提供有限范围的切片，而不是倾倒整个文件。

Git 和 PR 智能 — 代码有历史

源代码说明当前发生了什么。Git 说明代码如何演变至此。历史记录、blame、所有权、变更频率和 PR 分析会为静态模型补充变更证据。

记忆 — 持久化 rationale，而非 Truth 的替代品

项目记忆会保存事实和决策。团队记忆包含修订、actor/source 元数据和冲突处理行为。记忆会保留“为什么”，但其可信度不会被视为高于源代码和测试。

架构智能 — 让结构变化清晰可见

架构推断会返回证据和置信度。系统会将已保存的指纹与当前图进行比较，以发现依赖方向和耦合的漂移。

影响分析和验证 — 了解影响范围

影响分析会追踪反向关系和受影响的测试。验证会依据仓库证据审视提议的变更。

---

受控编辑

当前语义操作：

cortex edit rename src/auth.py AuthService SessionService
cortex edit replace src/auth.py AuthService/refresh --body-file ./replacement.txt
cortex edit insert-before src/auth.py AuthService --body-file ./imports.txt
cortex edit insert-after src/auth.py AuthService --body-file ./helper.txt

变更准则：

充分阅读
→ 了解影响
→ 限定范围后修改
→ 验证

而不是：

到处替换
→ 希望测试能通过

---

MCP：面向 Agent 的统一界面

cortex mcp --path /path/to/repository

MCP 提供仓库映射、符号搜索、引用、依赖图、影响分析、混合检索、紧凑上下文、架构、Git、PR、记忆、工作区、追踪、验证和统计信息。

类别	Agent 请求
仓库	映射、节点、图计数
符号	程序单元和位置
引用	目标附近的关系
依赖	本地调用/导入
影响分析	直接、间接、受影响的测试
检索	语义/词法/结构命中
上下文	具有明确预算的证据
架构	结构 + 漂移
历史	Git + blame + 所有权
拉取请求	符号 + 影响分析 + 测试 + 风险
记忆	项目和团队知识
工作区	跨仓库搜索
追踪	执行摘要
验证	验证证据
统计信息	仓库 + 图 + Git + 运行时

---

分布式操作

flowchart TB
    AG[AI Agents] --> GW[Remote MCP Gateway]
    GW --> AUTH[Authentication]
    AUTH --> POL[Tool Policy + Quotas]
    POL --> COORD[Coordinator]

    COORD --> IDX[Index Workers]
    COORD --> RET[Retrieval Workers]
    COORD --> CTX[Context Workers]

    IDX --> GRAPH[(Graph State)]
    RET --> VEC[(Persistent Vector Store)]
    CTX --> MEM[(Synchronized Team Memory)]

    COORD --> AUDIT[(Audit + Performance History)]

Worker 会声明能力，工作会被租用，过期的工作可以重新入队。远程操作可以具备 auth、TLS、配额、工具策略、组织/工作区策略和审计证据。

Dashboard 是可观测性界面，而非授权机制。

---

Observatory

cortex dashboard -p /path/to/repository

Observatory 可以显示：

后端健康状态
路由分布
上下文使用情况
引擎延迟
图热点
任务追踪
架构漂移
基准测试历史
拉取请求风险

上下文引擎必须能够说明自身的路由、证据来源和故障状态。

---

مدل امنیت

مرز	کنترل
Source path	محدود به project root
Semantic edit	preflight + path boundary
Task trace	bounded attribute + redaction
Backend اختیاری	process isolation
Remote MCP	auth قبل از dispatch
Remote tools	policy + allow list + quota
Organization	role + workspace policy + audit retention
Dependency	audit + dependency review
Source	static analysis + CodeQL
Release	checksum + SBOM + signature + provenance

Badge امنیتی evidence است، نه تضمین امنیت همه deploymentها. Threat model مخصوص محیط همچنان لازم است.

---

دکترین Quality، Release و Benchmark

commit دقیق
→ quality matrix
→ security checks
→ build
→ smoke test
→ checksum
→ SBOM
→ signature / attestation
→ release

Integrationای که credential ندارد باید skipped گزارش شود، نه success.

Benchmark:

python scripts/run_production_benchmark.py

Claim performance باید به spec بازتولیدپذیر، revision پین‌شده، environment، measured result و artifact وصل باشد. CodeCortex نباید token saving، speedup، task success یا accuracy ساختگی منتشر کند.

---

لایه Evidence Fusion

وضعیت: منتشر شده. implementation، test، benchmark، documentation و سوابق provenance همگی داخل ریپو هستند. هر سه لایه اختیاری‌اند: هسته CodeCortex بدون هیچ‌کدام از آن‌ها و بدون دسترسی شبکه کار می‌کند.

CodeCortex چند نوع evidence را با هم ترکیب می‌کند و برای هر نتیجه می‌گوید آن نتیجه چطور اثبات شده است. هر رکورد یک trust tier مشخص دارد — exact، near_exact، structural، inferred_high، inferred، weak — به‌همراه برچسب provenance. دو قاعده در خودِ کد اجرا می‌شوند، نه فقط در مستندات: هیچ evidence‌ای تا وقتی تازه نباشد نمی‌تواند ادعای exact کند، و evidence قدیمی هرگز بالاتر از evidence ساختاری تازه رتبه نمی‌گیرد.

مدل کامل، رفتار fallback و مرزهای امنیتی در docs/EVIDENCE_FUSION.md آمده است.

۱ — Precision Code Intelligence

لایه Precision Code Intelligence در صورت وجود evidence دقیق compiler/indexer-grade تفاوت این سطوح را تشخیص می‌دهد:

definition/reference دقیق
        با
relationship ساختاری
        با
candidate heuristic
        با
lexical coincidence

قابلیت‌های فعلی:

• definition دقیق؛
• reference دقیق؛
• implementation relationship؛
• occurrence سیمبل؛
• stale-index detection؛
• fusion گراف با provenance دقیق/استنباطی؛
• fallback به intelligence فعلی.

flowchart TB
    EX[Exact index/compiler evidence] --> F[Evidence Fusion]
    SEM[Language-aware semantic evidence] --> F
    AST[AST / structural evidence] --> F
    GR[Graph inference] --> F
    HEU[Heuristic resolution] --> F
    LEX[Lexical match] --> F
    F --> CTX[Task-ranked context]

سیستم باید فقط نداند چه پیدا کرده؛ باید بداند چقدر دقیق می‌داند.

۲ — Dependency Intelligence با آگاهی از نسخه

لایه Dependency Intelligence این اطلاعات را کنار هم قرار می‌دهد:

manifest
+ lockfile
+ نسخه declared
+ نسخه resolved
+ usage داخل repository
+ documentation مربوط به همان نسخه

سؤال‌هایی که این لایه پاسخ می‌دهد:

• نسخه واقعی resolveشده چیست؟
• API پیشنهادی برای همین نسخه معتبر است؟
• pattern فعلی قدیمی است؟
• migration guidance مرتبط چیست؟
• کدام file و symbol از dependency استفاده می‌کند؟

Documentation بیرونی باید optional، minimal-data، credential-aware، cacheشده و explicit باشد. Core باید offline هم کار کند. سورس ریپو نباید برای جواب dependency question به‌صورت پیش‌فرض از سیستم خارج شود.

۳ — Structural Search و Guarded Rewrite

لایه Structural Search و Guarded Rewrite برای patternهای syntax-aware:

callهایی با شکل old_api($X)
constructor با option قدیمی
handler با exception pattern خاص
همه usageهای ساختاری قبل از migration

جریان mutation:

flowchart LR
    Q[Migration request] --> S[Structural search]
    S --> M[Match set]
    M --> I[Impact analysis]
    I --> P[Rewrite preview]
    P --> A{Mutation allowed?}
    A -- No --> STOP[Preview only]
    A -- Yes --> W[Bounded rewrite]
    W --> R[Reindex]
    R --> V[Validation]
    V --> POST[Post-change impact]

Rewrite باید preview، bound، content-hash check، policy authorization، reindex و validation داشته باشد.

真正目标：证据融合

未来任务示例：

将身份验证中间件迁移到此项目所用版本对应的正确 API。

理想流程：

依赖清单
→ 已解析版本
→ 当前中间件
→ 精确引用
→ 对应版本的文档
→ 结构性匹配
→ 受影响的符号和测试
→ 受保护的重写预览
→ 变更策略
→ 验证
→ 变更后的影响

核心价值不在于三个独立工具，而在于一个上下文引擎，它能将代码的本地事实、精确关系、依赖版本、结构模式、历史记录和验证整合为一个任务所需的上下文包。

---

当前状态和回退行为

功能	已发布	未安装可选层时的回退行为
符号	语言感知解析 + 精确匹配融合	结构解析和启发式方法
引用	精确/推断式层级结构	图 + 语义智能
依赖	已解析版本 + 可选文档	仅本地清单信息 + 明确标注“文档不可用”
搜索	词法 + 语义 + 结构 + AST 模式	词法和符号搜索
编辑	受控编辑 + 基于预览的迁移	仅受控语义编辑
影响	感知证据质量的影响分析	图遍历 + 受影响的测试
上下文	跨提供方的统一排序	排序 + 去重 + 预算
置信度	来源信息 + 信任等级	明确标示歧义
离线	本地优先	不变；网络绝非必需

---

使用配置

配置	常见形式
Solo	本地仓库 → 本地索引 → 本地记忆 → MCP Agent
Team	共享约定 → 团队记忆 → 工作区 → PR 智能分析
Large workspace	多个仓库 → 联合证据 → 远程认证界面
Distributed	网关 → 策略 → 协调器 → 工作器 → 持久化存储

---

CodeCortex 不是什么？

不是什么	原因
通用聊天	它的工作是仓库上下文智能
模型提供方	证据能让模型表现更好
神奇的正确性保障层	模型和人仍会出错
测试的替代品	验证需要可执行证据
Git 的替代品	它将历史记录转化为上下文
向量数据库产品	存储可替换
源代码事实的替代品	源代码仍是权威依据
基准测试宣传页面	声明需要有产物支撑

---

设计规则

1. 边界类型化。
2. 智能可替换。
3. 本地优先。
4. 明确上下文预算。
5. 默认采用项目级状态。
6. 摘要之后仍保留来源信息。
7. 变更权限独立。
8. 分布式状态明确。
9. 不捏造缺失的证据。
10. 发布声明需要证据支撑。

---

命令路线图

cortex init .
cortex index
cortex architecture
cortex architecture-drift
cortex semantic "authentication refresh"
cortex impact AuthService
cortex symbol-history src/auth.py 10 80
cortex pr main --head HEAD
cortex workspace-add backend ../backend
cortex workspace-search "payment service"
cortex definition src/auth.py 12 7
cortex references src/auth.py 12 7
cortex precision-status
cortex dependency next
cortex dependency-docs next "middleware authentication"
cortex structural-search --lang python --pattern 'old_api($X)'
cortex rewrite-preview --lang python --pattern 'old_api($X)' --replacement 'new_api($X)'
cortex rewrite-apply <preview-id>
cortex benchmark
cortex evidence-benchmark
cortex dashboard
cortex doctor
cortex mcp --path .

---

Docker

docker build --target core -t codecortex:core .
docker build --target full -t codecortex:full .
docker compose up dashboard

容器化不能替代适当的身份验证、TLS、策略、密钥管理和威胁模型。

---

项目状态

CodeCortex 目前处于 Alpha 阶段。

公共接口仍在演进，1.0 之前可能会有破坏性变更。应根据代码、测试、CI、文档和可复现产物实际展示的内容来评估项目。

---

سناریوهای مهندسی

مأموریت	شروع	Verify
Onboarding	architecture + repository map	source + execution path
Bug investigation	semantic + symbol + history	targeted test
Feature	pattern موجود + dependency	architecture + test
Refactor	reference + impact	staged edit + contract test
Dependency migration	import + usage + assumption	compatibility check
Security review	trust boundary + call path	negative/adversarial test
PR review	changed symbol + impact	affected test + drift
Release readiness	CI + security + benchmark	artifact commit دقیق

---

مشارکت در پروژه

Good First Issues · گزارش باگ · راهنمای مشارکت

مستندات

• Architecture
• Distributed
• Advanced Intelligence
• Evidence Fusion
• Integrations
• Quality
• Testing
• Release
• Licensing
• Security
• Contributing
• Governance
• Roadmap
• Cloud & Enterprise Early Access

---

سؤال‌های پرتکرار

آیا CodeCortex جای مدل را می‌گیرد؟

نه. مدل reasoning و generation را انجام می‌دهد. CodeCortex محیط evidence را بهتر می‌کند.

Core به سرویس remote نیاز دارد؟

نه. Core local-first است. provider اختیاری می‌تواند boundary ریموت صریح داشته باشد.

Context window خیلی بزرگ این پروژه را بی‌نیاز می‌کند؟

نه. اندازه window و کیفیت evidence دو مسئله متفاوت‌اند.

همه relationshipها دقیق‌اند؟

نه. رابطه‌های استنباطی ambiguity را نگه می‌دارند. Precision Code Intelligence در صورت وجود، evidence دقیق compiler/indexer را اضافه می‌کند و در نبود آن محافظه‌کارانه fallback می‌کند.

چند ریپو را پشتیبانی می‌کند؟

بله. Workspace evidence را federate می‌کند و هویت repository را نگه می‌دارد.

می‌تواند کد را edit کند؟

Semantic editing کنترل‌شده از backend مناسب در دسترس است. Read intelligence و mutation privilege جدا هستند.

---

نگهداری، مشارکت و License

CodeCortex توسط Behnam Jalali ساخته و نگهداری می‌شود.

python -m pip install -e ".[dev]"
ruff check .
mypy src/codecortex
pytest

بخش‌های متعلق به CodeCortex تحت Apache License 2.0 منتشر می‌شوند. اجزای ثالث تابع license و attribution ثبت‌شده در خود ریپو هستند.

فایل‌های LICENSE، NOTICE، SECURITY.md و CONTRIBUTING.md را ببینید.