This page compares complete frameworks: their product forms, strengths, weaknesses and missing capabilities. Six subsystem comparisons already cover sandboxing, agent collaboration, long-term memory, memory adoption, speaker identity and chat attachments. This page uses their conclusions without repeating their detail. Twelve dimensions each have a concise assessment and a diagram; detailed evidence stays in the subsystem documents.
The investigation answers these three questions. The twelve-dimension matrix and missing-capability inventory provide the supporting evidence.
Among the twelve references, no second implementation was confirmed to record the function call tree in conversation history. Model tool results and successfully persisted function calls with session DAG recording enabled, excluding expose=hidden, are recorded at the Agent method call level as code nodes in the session DAG. They share caller/predecessor edges with user and llm nodes and reside in the same session Git repository. Multiple heads can reference different history branches.
OpenClaw and pi-mono both support transcript branching. OpenClaw Control UI provides fork, rewind and branch; pi-mono JSONL records carry parentId and /tree switches branches. OpenProgram additionally shares a DAG across user, llm and code nodes, with code nodes representing both tool results and nested calls. Transcript branching and worktrees are independent: agent branches share the current working directory by default; only jobs explicitly bound to worktree_id isolate file changes.
OpenProgram supports bundled, dynamic community and custom providers, an MCP client, skills and plugins. External programs can invoke tools through an authenticated stdio MCP server and drive sessions through an ACP server. An OpenAI-compatible endpoint, stable versioned remote-control SDK, complete public headless event protocol and maintained IDE extension remain unconfirmed. Owner-authenticated WebSocket and Python library entry points are internal or embedded interfaces; they do not provide these external compatibility commitments.
For project instructions, OpenProgram and OpenClaw both store agent-level guidance in agent workspaces. OpenClaw provides migrate-claude and migrate-hermes. Codex desktop/CLI import can migrate Claude Code and Cursor setup and recent work. OpenProgram currently has no importer for external agent sessions, configuration or skills.
Instead of emitting tool calls, the model writes JavaScript that invokes tools in the current turn. In CodeModeOnly mode, the model-visible tools are limited to exec and wait. Four crates and a V8 runtime implement this feature, which the feature registry disables by default; examining only default behavior would miss it.
OpenProgram lets a model generate a workflow package, then execute a versioned Python workflow after static validation and atomic publication. Codex code mode instead generates JavaScript and invokes tools immediately within the current turn. OpenProgram currently has neither this per-turn code mode nor a model-visible tool set reduced to exec/wait as its two entry points.
A general-purpose Python agent harness. Installation provides the openprogram command and a persistent worker. TUI, Web, Electron desktop and four chat channels share process_user_turn through the dispatcher; the Python library enters through Agent.run or Runtime directly into agent_loop. Each session’s Git repository is the source of truth for its transcript. SQLite holds the usage ledger. Memory content is Markdown, with rebuildable in-memory BM25/embedding indexes for retrieval. Workflows can be Python functions decorated with Agent method; nested calls that meet recording conditions and persist successfully enter the same session DAG. The history/ JSON nodes support updates and deletion; context/commits/ is frozen per turn. Providers can be bundled, dynamic or custom. Web and WebSocket entry points enforce single-owner authentication through owner_auth, using a per-start token and profile-specific cookie. This is a single-user framework, not a multitenant service.
First-party source lines use one counting method: .py/.ts/.tsx/.js/.rs/.go only, excluding tests, node_modules, dist, target and vendor. The horizontal axis is logarithmic because the largest and smallest differ by 350 times. This indicates differences in complexity, not capability quality.
openprogram/ at about 134 thousand.
Capability conclusions for Claude Code, Codex, OpenClaw and OpenCode were checked against official stable releases and documentation on 2026-09-01. Code counts, internal implementation details and other references continue to use fixed versions from references/ and locally installed packages. These two evidence types are not presented as a complete source audit from one date.
control-plane/move-session.ts can relocate a session and Git changes within a project to another absolute directory or worktree, but cannot move them to another machine or take over an active turn. OpenProgram already has a persistent worker, WebSocket clients and per-session Git storage. Cross-worker migration would still require a versioned migration protocol, target placement, authentication, active-turn semantics and failure recovery.
Each cell gives a concise assessment. OpenProgram’s column is colored by the assessment: green = ahead, orange = comparable, red = behind. Scroll the wide table horizontally.
| Dimension | OpenProgram | claude-code | codex | openclaw | opencode | hermes-agent | pi-mono | weclaw |
|---|---|---|---|---|---|---|---|---|
| Product form | General-purpose harness | Coding CLI + cloud | Coding CLI + cloud | Multichannel gateway platform | Coding CLI + SaaS services | Personal assistant + research harness | Coding TUI + library | WeChat relay |
| Target user | Single local user | Individual, subscription or enterprise | Individual; seven configuration layers | Single operator; multiple channel users | Individual developer | Individual; pairing codes for strangers | Single local user | Individual; no authentication |
| Execution model | Persistent worker | In-process + daemon + cloud containers | In-process + App Server + cloud | Gateway + paired devices, opt-in cloud workers and managed worktrees | Local client/server separation | In-process + gateway daemon | Single process | Forwarding daemon |
| State storage | Git per session | JSONL files per project | Rollout JSONL + five SQLite databases | Per-agent SQLite for runtime state and transcripts; JSONL only for archives or legacy migration | SQLite + Drizzle | SQLite + FTS5 | JSONL session tree | In memory; lost on restart |
| Context assembly | L0/L1/L2 component registry | Static prefix + dynamic boundary markers | Per-model prompts compiled into the binary | Workspace files + bootstrap budget | 13 model-specific prompt sets | Three layers: stable/context/volatile | Prompt restricted to enabled tools | None |
| Project instructions | AGENTS.md in agent workspace | Four CLAUDE.md levels, including system-wide | AGENTS.md accumulated below Git root | Workspace AGENTS/SOUL/TOOLS | Global + project; first match | Four formats + subdirectory guidance | All ancestor directories | None |
| Tool surface | Dynamic registry; persistent presets + deferred tool_search catalog | About 24 exposed tools; ToolSearch | About 28; code mode can reduce to two | About 35 in 11 groups; tool_search | 16; model-dependent apply_patch | About 82; 32 toolsets | Seven; three disabled by default | Zero |
| Permission approval | Five modes + rules + tool.before gate | Six modes: default/acceptEdits/plan/auto/dontAsk/bypassPermissions | Four, including Granular; execpolicy DSL | Layered restrictions; approval cards in chat | Ask by default; Bash command tokenization | 55 dangerous patterns; auxiliary-LLM auto-approval | None; tool allowlist only | Automatically approve all |
| Extensions | Plugins + skills + MCP client + 32 events | Plugin marketplace + 27 hooks + 122 commands | Plugin marketplace + 11 hooks; model can self-install | 126 plugins + 59 skills + ClawHub | Plugins with 19 hooks; can render inside TUI | 20 hooks + shell-script hooks + 178 skills | About 40 events + package manager; no MCP | Configuration file only |
| Channels | Four | Mobile Web bridge, Slack, Discord | Slack integration; depends on cloud account and workspace configuration | Ten native channels; over 20 plugin channels | GitHub + Slack + ACP + two IDEs | About 26, plus webhooks and cron | None | One |
| Interfaces | TUI + Web + Electron | Custom Ink fork + Vim + voice | ratatui; IDE context over sockets | TUI + control panel + macOS/iOS/watchOS/Android nodes | OpenTUI + Web + Electron | Ink TUI + React Web | Custom TUI framework that can run DOOM | Terminal only |
| External interfaces | Authenticated stdio MCP server + ACP; no stable remote SDK | MCP server + Agent SDK + session service | App Server + Python/TypeScript SDK; codex mcp-serverdeprecated | Three MCP server forms + OpenAI compatibility + 74 RPCs | HTTP service + JS SDK + ACP | MCP server + OpenAI compatibility + ACP | RPC mode + JSON mode + SDK | Local HTTP push |
| Observability and billing | Append-only ledger with cache reads/writes and itemized costs | OTel + Perfetto + BigQuery; budget limits | OTel + analytics; tokens but no currency amounts | Trace export + OTel + Prometheus | OTel + data lake; stats command | Log redaction + Langfuse; provider quota retrieval | Optional installation counts; scripted cost aggregation | One log file |
| First-party source lines | 254,320 | 512,685 through 2026-04 | 1,070,595 | 1,987,813 | 366,499 | 544,917 | 116,599 | 5,723 |
Four Tencent CLIs are installed locally. The first three adapt upstream projects for an intranet; their modifications show what a framework intended for other users must consider. codebuddy-code is independently developed and offers the strongest comparison. No readable local implementation of ByteDance Trae is available, so no speculative assessment is included.
| Package | Form | Changes from upstream | Size |
|---|---|---|---|
| claude-code-internal v1.1.9 |
Not a source fork, but a launcher wrapper. It depends on upstream @anthropic-ai/claude-code@2.1.154 unchanged; modifications are confined to environment variables and proxying. |
Replaces endpoints with an intranet gateway; retrieves a model allowlist from that gateway; maps both Opus and Sonnet to GLM-5.1; redirects the configuration directory to ~/.claude-internal; prevent users from overriding it (scans settings files and removes all ANTHROPIC_* keys). Disables upstream telemetry and replaces it with intranet reporting that includes the Git repository and commit. Three authentication methods include device-code flow for CI. A local MITM proxy daemon uses fixed port 12639. Server-provided startup announcements require acknowledgment. |
388 lines 133 KB |
| codex-internal v0.0.8 |
Also a wrapper around upstream @openai/codex@0.118.0. |
rewrites config.toml to inject and force an intranet provider; disables upstream update checks and feedback reporting; injects request-header mappings so each request reports open repositories, YOLO mode and session ID to the gateway; restricts capabilities: codex mcp add by rejecting changes to administrator-managed settings; codex app-server exits immediately. Clears inherited OPENAI_* and CODEX_HOME, and binds the user ID and email to the subprocess environment. |
502 lines 572 KB |
| gemini-cli-internal v1.9.0 |
The only actual source fork. | among the three. Adds a codebuddy/ core module as a fourth ContentGenerator backend alongside Google; the authentication enum gains two variants (intranet GitLab OAuth and intranet API key). Existing Google methods remain, so one binary works inside and outside the intranet. Reports repository remotes and submodule paths to the gateway; passes API keys into sandbox-container environments. |
576,579 lines 25 MB |
| codebuddy-code v2.109.3 |
Tencent’s own implementation, internally named genie, built on an IoC container. It has 44 tools, many named similarly to claude-code (Agent, Skill, ToolSearch, EnterWorktree, SendMessage, TeamCreate), plus LSP, ComputerUse, CronCreate, Workflow and WeChatReply/WeComReply. | Prompts and tool authorization are data rather than code: a 326 KB product.json contains 109 Nunjucks templates, per-agent tool allowlists, model allowlists and command tables. Changing deployment changes this file: SaaS, intranet, zero-trust, self-hosted and cloud-hosted modes share one codebase. Sessions are stored as ~/.codebuddy/projects/<cwd-slot>/<uuid>.jsonl. A native sandbox binary has bubblewrap/seatbelt fallbacks. A PWA named “CodeBuddy Code Remote Control” controls local sessions from a mobile browser. Headless mode is a separate webpack artifact, not a CLI flag. |
2,629 bundled lines 21.7 MB plus 16 MB of headless |
vendor/shim/safe-bin/ contains rm／rmdir／unlink as three PATH replacements, active only when a session environment variable is present. A sitecustomize.py loaded automatically through PYTHONPATH patches os.remove／shutil.rmtree／pathlib and redirects deletion to the bundled trash binary. This operates below the tool layer and also covers agent subprocesses. OpenProgram now injects common shell, Python and Node deletion interception into local agent subprocesses bound to a session/turn and provides trash list/restore. Cron, background jobs, Docker, SSH, absolute-path commands, direct syscalls and disabled injection remain outside coverage.
Two: measure AI-written changes. A Git HEAD watcher attributes per-file change proportions to the agent or human and reports them. This is a management metric rather than an end-user feature, but demonstrates the enterprise requirement for auditable agent output.
Three: remote enterprise policy with a fail-open cache. The organization server decides whether users may add custom models or upload skills; decisions are cached locally.
Four: compliance content policy appears at the start of the system prompt, with client-side interception before model execution.
The six subsystem comparisons investigate existing questions. This section checks the twelve reference capability inventories for previously omitted mechanisms. Some entries now have an implementation basis; each row distinguishes implemented boundaries from candidates still requiring verification. Inclusion is not implementation approval.
| Available in | Mechanism | Why it was missed | Assessment |
|---|---|---|---|
| Theme 1 · Challenges to the current approach | |||
| codex | code mode: the model writes JavaScript to invoke tools rather than emitting tool calls. CodeModeOnly exposes only exec and wait. Four crates and a V8 runtime; disabled by default.code-mode / code-mode-host / code-mode-protocol / code-mode-runtime / v8-poc |
OpenProgram’s agentic-programming approach turns workflows into Python in advance for agents to invoke. It has not explored having the model write tool-invoking code during the turn. These are two forms of the same approach; only one is implemented here. | Warrants a separate comparison. It also demonstrates a different tool-selection mechanism: exposing the entire tool surface through one exec entry. |
| hermes | The harness generates training data: run datasets in batches, sample the toolset visible to each example from a probability distribution, compress trajectories into a token budget and connect them to the Atropos reinforcement-learning environment.batch_runner.py · toolset_distributions.py · trajectory_compressor.py · environments/ | OpenProgram treats tool selection as a permission question—what an agent may use. This system treats it as sampling the observation space for a training example. The same control serves two purposes. | Training pipelines are outside the current scope. Trajectory export currently provides human-readable output only; a complete versioned format remains a candidate requiring separate design approval. |
| Theme 2 · Adoption by other users | |||
| codex openclaw |
Import users’ data from other agents. Codex has an approximately 16-thousand-line external-agent-migration crate that imports sessions, configuration and skills from other agents, including claude-code, and keeps external_agent_session_imports.json on disk. OpenClaw has migrate-claude and migrate-hermes as two extensions. |
Feature completeness has received attention, but importing months of conversations and configuration from another tool has not. Migration support addresses an adoption problem through engineering. | Not implemented. Session and configuration import remain candidates requiring separate design approval. Reading an external skills format is not an implemented migration. |
| codex | A 105-entry feature registry with lifecycle stages: features/src/lib.rs records each capability as Stable, UnderDevelopment, Experimental, Removed or Deprecated, with default_enabled for each entry. One third of shipped capabilities are disabled by default. |
OpenProgram’s capabilities are distributed through the code, without one registry showing which capabilities ship in each version or depend on experimental switches. An earlier audit mistakenly classified Codex long-term memory as unimplemented because the complete subsystem was disabled by default. | Not implemented. A unified feature registry remains a candidate requiring separate design approval. |
| codebuddy | Five deployment profiles; prompts and tool authorization are data: 109 prompt templates, per-agent tool allowlists and model allowlists reside in one product.json. SaaS, intranet, zero-trust, self-hosted and cloud-hosted deployments replace that file without changing code. |
OpenProgram’s system-prompt components are Python functions, and tool authorization is in agent.json, but there is no replaceable deployment profile containing the complete configuration. |
Partly applicable. The component registry already supplies the structure; the missing part is externalizing the full set of values into one replaceable profile. |
| opencode | Control plane: relocate sessions and Git changes within one project to another directory or worktree, and publish a session at a public URL (incremental updates stream into a Durable Object and object storage; self-hosting is also supported).control-plane/move-session.ts · share/share-next.ts | OpenProgram treats sessions as local assets. Per-session Git repositories can support the design of local directory relocation and public sharing, but corresponding product entry points do not currently exist. | Evaluate local relocation and public sharing; cross-worker migration requires a separate protocol design. |
| Theme 3 · Agent trust | |||
| codebuddy | Intercept deletion below the tool layer: put rm／rmdir／unlink replacements on PATH and load sitecustomize.py through PYTHONPATH to patch Python deletion APIs, redirecting deletion to a trash binary. Agent subprocesses are covered too. |
OpenProgram covers common shell, Python and Node deletion entry points in local agent subprocesses bound to a session/turn. Unbound cron and background jobs, Docker, SSH, absolute-path commands, direct syscalls and disabled injection remain outside coverage. | Partially implemented. Remaining coverage is still a candidate for assessment. This mechanism is not a complete security boundary. |
| codex | execpolicy: command allowlists use a dedicated small language, with rule files distributed to ~/.codex/rules/default.rules, separate from the operating-system sandbox. It also has guardian, which uses an LLM to review approval prompts. |
OpenProgram permission rules use string matching and fnmatch. They cannot express checks such as “the command’s third argument must not be an absolute path.” Reviewing approval decisions is also an unexplored question. | Defer the DSL. A guardian is worth evaluating because it addresses the unresolved state in Gate.ask approval decisions. |
| openclaw | Record sandbox capability separately from default behavior: backends support Docker, Podman, SSH and OpenShell; mode accepts off／non-main／all and defaults to off. Docker mode defaults to no network, a read-only root filesystem, a non-root user and dropped capabilities. Official documentation also states that it is not a perfect security boundary. |
The presence of a Docker backend does not imply isolation is enabled by default. Compare backend capability, activation scope, defaults and security guarantees separately. | Consider Docker’s restrictive defaults without treating containers as a complete trust boundary. Acceptance must check both the default mode and actual launch arguments. |
| openclaw | The extension marketplace and public Gateway are separate attack surfaces: ClawHub allows anyone to publish skills, and malicious instruction-injection cases have occurred. Gateway has CVE-2026-25253. |
OpenProgram skills and the owner-authenticated Gateway assume a single local user. A skill marketplace introduces untrusted publishers; a public service introduces remote attackers. Both change existing trust assumptions. | A skill marketplace requires publisher identity, permission descriptions, scanning, takedown and installation confirmation. Public service exposure separately requires authentication, binding defaults, patch response and version upgrades; local-only assumptions cannot be reused. |
| codebuddy | Measure AI-written code: a Git HEAD watcher attributes and reports per-file agent versus human changes. | OpenProgram records tokens and costs, not output attribution. Enterprises may require the latter. | Record locally before adding reporting. Per-turn Git commits already provide attribution data. |
| openclaw | Trajectory export: package the system prompt, tool definitions and every event after redaction, using a versioned format with 10 MB / 50 MB / 256 KB limits.src/trajectory/ | OpenProgram exports sessions as Markdown or HTML with redaction enabled by default. Output is intended for human reading and truncates tool arguments and results. It does not yet package system prompts, complete tool definitions, runtime events, provider artifacts, usage/cache data and runtime settings into a versioned trajectory. | Partially implemented. Complete structured trajectories remain an unconfirmed candidate. |
| Theme 4 · Proactivity and testing | |||
| openclaw | Automations + Heartbeat: Automations support cron, fixed intervals and one-time tasks, delivering results to chat channels or webhooks. Heartbeat runs a proactive main-session turn every 30 minutes by default and reports only noteworthy items. | OpenProgram Scheduler persistently registers one-time, recurring and monitoring tasks, with signed execution, retries, recovery and a persistent worker. It runs agent prompts or controlled commands. It has no result-delivery protocol for chat channels or webhooks, and no default main-session heartbeat with importance filtering. | Two independent scopes remain: a Scheduler result-delivery protocol, and a main-session heartbeat with frequency, quiet-period and filtering rules. Both require separate design approval. |
| openclaw | Commitment tracking: extract implicit commitments from chat into typed entries (agreements, deadlines, concerns and unfinished work), using a confidence threshold of 0.86 and at most three proactive messages per day. Heartbeat and one-time startup actions are separate proactive paths.src/commitments/ | OpenProgram’s proactive layer executes explicitly registered external events or Scheduler tasks. Ordinary conversation content does not currently create future actions automatically. | Automatic commitment extraction would need a confidence threshold, daily message limit, revocation mechanism and false-trigger handling. Implementation is not currently approved. |
| openclaw | Dreaming: background processing extracts entries above a score threshold from daily notes in memory/YYYY-MM-DD.md and promotes them to MEMORY.md. An automatic pre-compaction memory flush separately saves information suitable for long-term retention. |
OpenProgram memory has nightly reorganize(), but no explicit scored promotion lifecycle from daily notes into core memory. Pre-compaction extraction and background organization are distinct stages. |
Continue comparing this as a layered-memory mechanism. Define scoring thresholds, automatic-write attribution and pre-compaction failure semantics together. |
| openclaw | Nodes expose remote device capabilities as tools: macOS, iOS, watchOS and Android have native nodes. Mobile nodes expose sensors, calendars and notifications; Android can use accessibility services for device control, while macOS provides computer.act desktop automation. |
OpenProgram channels only exchange messages; they do not register another device’s capabilities as agent tools. A node protocol and a native mobile application are separate choices. Declining to build a mobile app does not imply excluding remote-device tools. | A node protocol warrants a separate design. A native app is not a prerequisite; select device capabilities individually according to permissions, revocable authorization and platform cost. |
| pi-mono | Scripted provider + HTTP record/replay: a fully registered simulated model emits scripted text, reasoning and tool calls with configurable chunk sizes. HTTP and WebSocket record/replay stores recordings in test fixtures. | OpenProgram has a test-only scripted provider that uses normal registration to drive text, reasoning, tool calls, errors and multi-turn responses, including real agent_loop tool-result feedback. It is not a shipped production provider. |
Partially implemented. Shipping a production provider requires separate design approval. |
| pi-mono | Switch providers within a session: normalize reasoning-block signatures and tool-call IDs so the same history can continue across providers. A separate extension creates a new session using a generated handoff prompt. | OpenProgram Web/TUI can switch models in the same session. providers/_shared/transform_messages.py normalizes cross-protocol messages, reasoning blocks and tool-call IDs; tests cover cross-provider tool-call history. This differs from a handoff-prompt extension that creates a new session. |
Same-session cross-provider continuation is implemented; a separate new-session handoff workflow is not required by this contract. |
Distinctiveness matters only when it provides an additional capability. Two of these mechanisms do so; the third is currently distinctive mainly in its organization.
| OpenProgram mechanism | Definition | Closest counterpart | Resulting capability |
|---|---|---|---|
| Session DAG Branches are head pointers |
One graph, three node roles (user/llm/code), two edges (caller/predecessor). Each session uses a Git repository; history JSON nodes can be created, have output/metadata backfilled, or be deleted under a lock. meta.json uses CAS for the current head and optional branch refs; title/archive updates use lock-protected atomic replacement. The system does not maintain a mutable complete transcript snapshot. |
OpenClaw Control UI provides transcript fork, rewind and branch. pi-mono JSONL records carry parentId, /tree switches branches and summarizes abandoned branches. opencode fork creates a new session; codex agent graph records agent relationships. |
OpenProgram’s confirmed distinction combines transcript branches, a unified user/llm/code DAG and per-session Git storage. OpenClaw and pi-mono already support transcript branching; this capability cannot be attributed only to OpenProgram and pi-mono. OpenProgram does not automatically create a worktree per transcript branch. File isolation applies only to jobs explicitly bound to worktree_id. |
| Agent method Workflows implemented as code |
A Python decorator. With session DAG recording enabled, calls other than expose=hidden that persist successfully become code nodes in the session DAG, sharing edges and the same Git repository with user messages, model messages and tool results. |
No direct counterpart. pi-mono extensions, opencode tool/*.ts, hermes skills can register new tools, but their histories expose tool inputs and returns rather than internal execution steps.The complementary approach is Codex code mode: the model writes code to invoke tools during the turn. |
Successfully persisted internal steps can be reviewed with the conversation. Top-level manual functions can produce sibling branches through Retry/Edit. State restoration or replay from arbitrary nested steps is not implemented. |
| Four-domain collaboration tools todo／task／agent／message |
Four nouns define four domains: todo for plans, task for running work, agent for executors and message for communication. Each tool operates only on the noun in its domain, making naming systematic. | Other frameworks provide these capabilities without domain-based naming. opencode uses task plus todowrite; hermes uses delegate and a board; claude-code uses Task/TaskOutput/SendMessage/Brief; codebuddy includes TaskCreate/Get/Update/List/Stop/Output among its 44 tools without separating domains. |
The distinction is in naming, not capability. A separate comparison establishes the substantive difference: among eight references, only OpenProgram limits subagent tools by remaining message budget; its loop-prevention mechanisms are as extensive as OpenClaw’s.See runtime/agent-collab-comparison.html |
The following six items retain their original candidate scope while updating current implementation status. They do not authorize implementation. Remaining work requires separate design, estimation and approval; this page does not add an implementation plan.
| ID | Item and current status | Verified boundary | Current location |
|---|---|---|---|
| 1 | Scripted provider: partially implemented. The test-only implementation emits scripted text, reasoning, tool calls, errors and multi-turn responses. | Normal provider registration already exercises the real agent_loop and tool-result feedback. A shipped production provider is neither implemented nor approved. |
tests/component/providers/scripted_provider.py · test_scripted_provider.py |
| 2 | MCP server: implemented. The CLI provides an authenticated stdio server exposing allowed OpenProgram tools. | It reuses existing tool registration, permission modes and allow-pattern mapping. A stable remote SDK, OpenAI-compatible endpoint and inbound webhooks are outside this implementation. | openprogram/mcp/server/server.py · apps/cli/python/openprogram_cli/_impl/commands/mcp.py |
| 3 | Trajectory export: partially implemented. Sessions export as Markdown or HTML with redaction enabled by default. | Current formats serve human reading and truncate tool arguments and results. System prompts, complete tool definitions, runtime events, provider artifacts, usage/cache data and runtime settings are not yet combined into a versioned structured package. | openprogram/store/session/export.py |
| 4 | Recoverable deletion: partially implemented. Local agent subprocesses bound to a session/turn have interception for common shell, Python and Node deletion operations, a manifest and trash list/restore. |
Unbound cron and background jobs, Docker, SSH, absolute-path commands, direct syscalls and disabled injection remain outside coverage. This is not a complete security boundary. | openprogram/sandbox/recoverable_delete.py · apps/cli/python/openprogram_cli/_impl/commands/trash.py |
| 5 | Feature registry and default stages: not implemented. | No unified runtime feature registry records each capability’s stage and default switch. The candidate requires separate design approval. | No unified feature registry |
| 6 | External agent session/configuration import: not implemented. | Existing external-CLI credential discovery does not migrate sessions, configuration, skills or history. The candidate requires separate design approval. | No external session/config importer |
Three framework-level targets correspond to the three opening questions.
A session is already a Git repository containing a complete graph. The target is to transfer that repository to another machine for continuation, publish a redacted version for others to inspect, and branch again from any node. All three operations use the same representation rather than three export formats.
MCP server and ACP already provide standard local entry points. The target additionally requires a stable versioned remote-control contract and external session/configuration import. These latter capabilities remain unapproved candidates.
Each capability has a registry entry recording its stage and default switch; every run can export a redacted complete trajectory. The registry makes supported behavior explicit, while trajectories make failures reproducible for others. Both are needed as complexity grows.
Major product capabilities were checked against official stable releases on 2026-09-01. Source structure, line counts and installed Chinese packages use fixed local versions. The table distinguishes these evidence types.
| Reference | Evidence source | Date | Notes |
|---|---|---|---|
| OpenProgram | integrated candidate@d91c3e66 code, CLI/Web/TUI entry points and corresponding tests | 2026-09-01 | MCP server, ACP, LSP, mid-turn steering, Scheduler, cross-session agent provenance, session export, cross-provider history compatibility and recoverable deletion were checked against current implementation boundaries. Design-only candidates are not marked complete. |
| claude-code | Official stable release v2.1.252 and official documentation | 2026-09-01 | Older reference source and local 2.1.226 supplement internal implementation evidence only; current public capabilities follow official stable-release evidence. |
| codex | Official stable release rust-v0.152.0 and official documentation | 2026-09-01 | Worktrees, cloud, Web, GitHub, Slack, Automations, import and App Server/SDK count as official public capabilities. Older local source only supplements internal structure. |
| openclaw | Official stable release v2026.8.1 and official documentation | 2026-09-01 | session SQLite/search/archive, paired devices, cloud workers requiring explicit profile configuration, managed worktrees, Control UI and Workboard were checked against documentation for the corresponding release. |
| opencode | Official stable release v1.18.25, tag-pinned source and official documentation | 2026-09-01 | Scout has a documentation/source discrepancy and remains unconfirmed in stable source. Worktree core exists, but routing remains experimental. |
| Four other references | references/ fixed source: Hermes, pi-mono, weclaw and the pi-ai protocol reference | Fixed version | Not claimed to be the latest releases; capability conclusions are limited to the specified evidence. |
| Four Chinese projects | Local~/.npm-global/lib/node_modules/ npm packages; inspect dist/bundled artifacts | 2026-08 | The first three are wrappers whose changes focus on environment and configuration; the Gemini variant is a source fork. |
| Trae | Implementation unavailable | — | Not installed locally; absent from /Applications, application-support directories, and VS Code/Cursor extension directories. No speculation. |
| Item | Older reference source | Fixed local binary | Use |
|---|---|---|---|
| claude-code subagent depth limit | Switch absent from the source tree | Present; defaults to three, supports environment override and staged rollout2.1.226 near @249432727 | Supplementary internal evidence; current public capabilities use v2.1.252 official evidence |
| claude-code per-agent tool filtering | Filtering exists but excludes depth | The filtering function directly receives agentDepth and exposes subagent-dispatch tools only below the depth limit. Three constant tables separately govern ordinary agents, asynchronous agents and coordinator mode.@256834891 · @75243888 · @75243840 · @75243792 |
Supplementary internal evidence; current public capabilities use v2.1.252 official evidence |
| claude-code Slack | Only a marketplace installation link | Complete Slack conversation interface, including bot/human-turn validation and channel search@78014240 · @106577664 · @106582768 · @70680752 | Supplementary internal evidence; current public capabilities use v2.1.252 official evidence |
| claude-code artifact publication | Entirely absent | Complete system: plan artifacts published as hosted HTML with script-hash allowlists, plus a separate artifact tool and feature switches@75228592 · @75228672 · @75228896 · @75229360 · @75180658 | Supplementary internal evidence; current public capabilities use v2.1.252 official evidence |
| claude-code scheduling and external triggers | None | Three scheduling tools, one remote-trigger tool and tools for self-hosted CI@75240320 | Supplementary internal evidence; current public capabilities use v2.1.252 official evidence |
| Codex long-term memory | A complete subsystem in source (two-stage read/write pipeline and its own database), marked Stable in the feature registry but default_enabled: false. Looking only at default behavior would incorrectly suggest it is absent; an earlier assessment made this error. |
Count as present | |
Layer 1 checks OpenProgram against the integration candidate. Layer 2 checks four major products’ public capabilities against official stable releases on 2026-09-01, while code counts and internal details remain tied to fixed local versions. Layer 3 updates six candidates; layer 4 describes a target not yet fully achieved.
| Item | Status | Location |
|---|---|---|
| Architecture diagrams, code size, twelve-dimension matrix, four Chinese projects, missing-capability inventory and distinctive mechanisms | Capabilities checked against the versions above; code size and internal structure represent fixed local versions only | Official stable-release evidence plus fixed references/ and local packages, as listed above |
| Six layer-3 candidates and three layer-4 targets | Candidates are not approvals; the target state is not fully implemented | See the scope of each layer-3 row |
| MCP server | Implemented | openprogram/mcp/server/server.py · apps/cli/python/openprogram_cli/_impl/commands/mcp.py |
| Scripted provider, trajectory export and recoverable deletion | Partially implemented | tests/component/providers/scripted_provider.py · store/session/export.py · sandbox/recoverable_delete.py |
| Feature registry and external agent session/configuration import | Not implemented; separate design approval required | No unified feature registry or external session/config importer |