Tools
Tools let the model act on the current workspace and connected services. The active runtime, permission policy, selected model, and available integrations determine which tools can execute.
Built-in tools
| Area | Tools |
|---|---|
| Files | list_files, glob_files, grep_files, read_file, write_file, edit_file, delete_file, rename_file, copy_file, create_folder, file_info |
| Search and navigation | semantic_search, open_file |
| Commands | run_command |
| Web | web_search, web_fetch |
| Images | vision |
| Skills | skill, install_skill |
| Subagents | subagent |
| MCP | mcp_search_tools, mcp_select_tool, mcp_features, plus selected server tools |
| Interaction and runtime | ask_user_question, memory, read_tool_result |
semantic_search is lexical repository search, not an embedding index. MCP tools are discovered lazily and namespaced to avoid collisions with built-ins.
fx does not currently include interactive browser or CDP tools.
See Web search for search selection, source scoping, citations, permissions, privacy, and the difference between web_search and web_fetch.
Background commands
The run_command tool can launch long-running operating system processes such as development servers and file watchers. Background processes return control immediately and keep a persisted record with their state, working directory, log path, and detected server URL when available.
Manage background processes inside the interactive shell:
/background
/background logs last
/background open last
/background stop last
Outside the shell, inspect the persisted records:
fx background --json
fx background last --json
Background commands are operating system processes. Subagents are separate fx sessions for delegated reasoning and tool work.
Large tool results
Large results are kept out of the immediate model response so one command or search does not consume the entire context window.
| Stage | What fx provides |
|---|---|
| Initial result | A bounded preview, the retained byte count, and a session-scoped handle. |
| Follow-up inspection | read_tool_result can read a byte range or search the retained result for a literal query. |
| Saved session | The redacted result remains outside session.json; its handle stays attached to the tool step. |
The model calls read_tool_result when it needs evidence beyond the preview. Handles must be copied exactly and work only with their session's tool-result store. The max_tool_result_bytes configuration field controls how many bytes fx retains from one tool result.
Vision
The vision tool provides the fallback for models that cannot receive attached images natively. See Vision for the native and fallback routes.
Memory
The memory tool keeps preferences across fx sessions when you explicitly ask fx to remember them.
savestores an exact fact and ignores duplicates.listretrieves the saved facts.clearremoves the complete memory file.
Saved facts live in ~/.fx/memories.json. They are not inserted into every model request; the model retrieves them through the tool when you ask it to remember, forget, or recall something. Do not use memory for secrets, temporary task notes, or repository facts that belong in project documentation.
Scope and permissions
File and command tools start from the primary workspace. Active additional directories extend that scope, but they do not bypass permission rules or the command sandbox.
ACP ask and code modes can use the full runtime set. Tool availability can still vary by entrypoint, model capability, platform, and integration state.
Tool calls are policy checked
A model choosing a tool does not guarantee execution. fx evaluates effective permission rules, session grants, mode, workspace access, and sandboxing first.