Skip to content

camel-ai

CAMEL is a multi-agent Python framework (package camel-ai) with toolkits for the terminal, browser, Gmail and files. It came into the catalog from the agent framework sweep for issue #64; see research/frameworks.md for the frameworks that got no catalog line. It is collected only, with no parser: CAMEL keeps no transcripts under the home.

Source and evidence

camel-ai/camel, Apache-2.0, open source, commit 24fde60ad739b4be8f8f533fea9ba54256fbc4a2 (2026-10-05), package camel-ai 0.2.91a7. All claims are from source.

CAMEL runs shell commands on the host: the terminal toolkit's shell_exec uses subprocess.Popen (terminal_toolkit.py:757, 838).

Observed

  • No real install: nothing was installed or run.

Source reviews

  • 2026-10-19: 797296a (package version unchanged, 0.2.91a7) against 24fde60, from source only. The home paths were unchanged; it added the caller-chosen tool log directory, the terminal toolkit's approval arguments and the absence of any sync (Per-user storage), and confirmed that there is nothing to parse.

Collection

Per-user storage

The home paths are the same at 797296a (gmail_toolkit.py:1316, skill_toolkit.py:206-207, runtime_utils.py:57).

Path (home-relative, all OSes) Holds Default or opt-in
.camel/gmail_token.json Google OAuth token and refresh token, mode 0600 (gmail_toolkit.py:1316, 1390-1402) default when GmailToolkit is used
.camel/skills, .config/camel/skills user-scope skills, read (skill_toolkit.py:201-209) read by default by SkillToolkit
.camel/runtimes/{go,java} downloaded Go and JDK toolchains (runtime_utils.py:57, terminal_toolkit.py:457-466) default when the terminal toolkit needs them; not collected

Everything else is relative to the working directory: ./workspace for the terminal toolkit (terminal_toolkit.py:188-195), ./camel_working_dir for the file toolkits (file_toolkit.py:69-73), ./chat_history.json for JsonStorage (json.py:71-73), and model logs only with CAMEL_MODEL_LOG_ENABLED, in CAMEL_LOG_DIR (default camel_logs) (base_model.py:287-295; the same at 797296a, base_model.py:287-295). The browser user_data_dir is supplied by the caller; save_memory(path) and a JsonStorage given a path write where the caller says (chat_agent.py:1780, json.py:72); and ChatAgent takes a tool_log_dir, new since 24fde60, that saves full tool outputs to a caller-chosen directory with no default (chat_agent.py:640-644).

Nothing else about a run is recorded. The model is chosen in code. The terminal toolkit's safe_mode, allowed_commands and require_approval callback are constructor arguments of the calling program (terminal_toolkit.py:143-148, 200-206), and no approval decision is written anywhere. Nothing syncs or relays a session (not found in camel/ at 797296a, grepped for share_url, upload_trajectory and sync_to), and there is no session to delete.

Scratch directories

The terminal toolkit's ./workspace and the file toolkits' ./camel_working_dir are the agent's own scratch space, created in the working directory (terminal_toolkit.py:185-195, file_toolkit.py:73), unrecorded and under no CAMEL-specific name, so no catalog line can find them.

Name collision

Apache Camel JBang also uses ~/.camel (CAMEL_DIR = ".camel" resolved under the home, CommandLineHelper.java:44, 221-222), so a bare .camel entry would collect JBang's state as camel-ai. The catalog names only .camel/gmail_token.json and .camel/skills, plus the CAMEL-only .config/camel.

Docker

No compose file or named volume.

Credentials

  • .camel/gmail_token.json: flagged. It is the one catalog line of real value: it shows that a Google account was granted to a CAMEL agent, which can then read and send mail as a tool.

Exclusions

.camel/runtimes would need one only if .camel were collected whole; it is not, so none.

Project-local files

The working-directory files in Per-user storage are created wherever the application runs, under no CAMEL-specific name, so they are not project catalog entries.

Where the project path is recorded

Nowhere under the home.

Parsing

CAMEL is collected only: there is nothing to parse, because it keeps no transcripts under the home. Its chat history, model logs, tool logs and saved memory are written in the working directory or wherever the calling program says (Per-user storage), so no catalog line reaches them and a parser would have no file to read.

Confidence

  • High for every path (source).