Qwen Code

read_file({ file_path: string, offset?: integer, limit?: integer, pages?: string })

Reads and returns the content of a specified file. The file_path argument MUST be an absolute path. Always construct it by combining the project root with the file's relative path (e.g. project root '/path/to/project/' + relative 'foo/bar.txt' = '/path/to/project/foo/bar.txt'). If the user provides a relative path, resolve it against the project root first. If the file is large, the content will be truncated. The tool's response will clearly indicate if truncation has occurred and will provide details on how to read more of the file using the 'offset' and 'limit' parameters. Handles text, images (PNG, JPG, GIF, WEBP, SVG, BMP), PDF files, and Jupyter notebooks (.ipynb). For text files, it can read specific line ranges. For PDF files, use the 'pages' parameter to extract specific page ranges as text (e.g. '1-5'). Max 20 pages per request. Large PDFs cannot be read all at once when the model does not support native PDF input; retry with narrower page ranges if the tool reports a PDF is too large. With a configured vision bridge, failed PDF text extraction or an irreducibly large single page may be transcribed automatically, at most four pages per call; this transcription is lossy and marked as untrusted. This tool can read Jupyter notebooks (.ipynb) and returns structured cell content with outputs.

Reads and returns the content of a specified file. The file_path argument MUST be an absolute path. Always construct it by combining the project root with the file's relative path (e.g. project root '/path/to/project/' + relative 'foo/bar.txt' = '/path/to/project/foo/bar.txt'). If the user provides a relative path, resolve it against the project root first. If the file is large, the content will be truncated. The tool's response will clearly indicate if truncation has occurred and will provide details on how to read more of the file using the 'offset' and 'limit' parameters. Handles text, images (PNG, JPG, GIF, WEBP, SVG, BMP), video, PDF files, and Jupyter notebooks (.ipynb); video (MP4, MOV, MKV, WEBM, AVI) require the selected model to support the corresponding modality. When multimodal support is enabled, video files are delivered to you for DIRECT perception — you can actually watch a video (frames + audio) by reading it. In particular, after you cut or downscale a media segment with a clip/extract tool, call read_file on the resulting clip to actually view/hear that segment yourself before answering — do not assume its contents. For text files, it can read specific line ranges. For PDF files, use the 'pages' parameter to extract specific page ranges as text (e.g. '1-5'). Max 20 pages per request. Large PDFs cannot be read all at once when the model does not support native PDF input; retry with narrower page ranges if the tool reports a PDF is too large. With a configured vision bridge, failed PDF text extraction or an irreducibly large single page may be transcribed automatically, at most four pages per call; this transcription is lossy and marked as untrusted. This tool can read Jupyter notebooks (.ipynb) and returns structured cell content with outputs.

Reads and returns the content of a specified file. The file_path argument MUST be an absolute path. Always construct it by combining the project root with the file's relative path (e.g. project root '/path/to/project/' + relative 'foo/bar.txt' = '/path/to/project/foo/bar.txt'). If the user provides a relative path, resolve it against the project root first. If the file is large, the content will be truncated. The tool's response will clearly indicate if truncation has occurred and will provide details on how to read more of the file using the 'offset' and 'limit' parameters. Handles text, images (PNG, JPG, GIF, WEBP, SVG, BMP), audio, PDF files, and Jupyter notebooks (.ipynb); audio (MP3, M4A, WAV, FLAC, OGG, AAC) require the selected model to support the corresponding modality. When multimodal support is enabled, audio files are delivered to you for DIRECT perception — you can actually listen to an audio file by reading it. In particular, after you cut or downscale a media segment with a clip/extract tool, call read_file on the resulting clip to actually hear that segment yourself before answering — do not assume its contents. For text files, it can read specific line ranges. For PDF files, use the 'pages' parameter to extract specific page ranges as text (e.g. '1-5'). Max 20 pages per request. Large PDFs cannot be read all at once when the model does not support native PDF input; retry with narrower page ranges if the tool reports a PDF is too large. With a configured vision bridge, failed PDF text extraction or an irreducibly large single page may be transcribed automatically, at most four pages per call; this transcription is lossy and marked as untrusted. This tool can read Jupyter notebooks (.ipynb) and returns structured cell content with outputs.

Reads and returns the content of a specified file. The file_path argument MUST be an absolute path. Always construct it by combining the project root with the file's relative path (e.g. project root '/path/to/project/' + relative 'foo/bar.txt' = '/path/to/project/foo/bar.txt'). If the user provides a relative path, resolve it against the project root first. If the file is large, the content will be truncated. The tool's response will clearly indicate if truncation has occurred and will provide details on how to read more of the file using the 'offset' and 'limit' parameters. Handles text, images (PNG, JPG, GIF, WEBP, SVG, BMP), audio, video, PDF files, and Jupyter notebooks (.ipynb); audio (MP3, M4A, WAV, FLAC, OGG, AAC) and video (MP4, MOV, MKV, WEBM, AVI) require the selected model to support the corresponding modality. When multimodal support is enabled, audio and video files are delivered to you for DIRECT perception — you can actually watch a video (frames + audio) or listen to an audio file by reading it. In particular, after you cut or downscale a media segment with a clip/extract tool, call read_file on the resulting clip to actually view/hear that segment yourself before answering — do not assume its contents. For text files, it can read specific line ranges. For PDF files, use the 'pages' parameter to extract specific page ranges as text (e.g. '1-5'). Max 20 pages per request. Large PDFs cannot be read all at once when the model does not support native PDF input; retry with narrower page ranges if the tool reports a PDF is too large. With a configured vision bridge, failed PDF text extraction or an irreducibly large single page may be transcribed automatically, at most four pages per call; this transcription is lossy and marked as untrusted. This tool can read Jupyter notebooks (.ipynb) and returns structured cell content with outputs.

File not found: <path>

Showing lines 1-1000 of 5000 total lines.

---

import { x } from "./x"
export const y = x

write_file({ file_path: string, content: string, record_as_artifact?: boolean })
edit({ file_path: string, old_string: string, new_string: string, replace_all?: boolean })
notebook_edit({ notebook_path: string, cell_id?: string, new_source?: string, cell_type?: "code" | "markdown", edit_mode?: "replace" | "insert" | "delete" })

Writes content to a specified file in the local filesystem. A request to create or generate a file does not establish that the target path is new. Unless the target's absence or current text contents have already been established in this session, you MUST use the read_file tool first; if the file does not exist, then create it. With prior-read enforcement enabled, blind overwrites are rejected. The file_path argument MUST be an absolute path. Always construct it by combining the project root with the file's relative path (e.g. project root '/path/to/project/' + relative 'foo/bar.txt' = '/path/to/project/foo/bar.txt'). If the user provides a relative path, resolve it against the project root first.

Artifact-like files such as HTML, PDF, images, notebooks, and office documents are automatically registered as session artifacts. Intermediate files that exist only to produce another artifact — for example HTML written solely to print a PDF — must set record_as_artifact=false, or be written under .qwen/tmp/ so they are not registered. Delete those intermediates when done.

The user has the ability to modify `content`. If modified, this will be stated in the response.

Replaces text within a file. By default, replaces a single occurrence. Set `replace_all` to true when you intend to modify every instance of `old_string`. This tool requires providing significant context around the change to ensure precise targeting. Always use the read_file tool to examine the file's current content before attempting a text replacement.

      The user has the ability to modify the `new_string` content. If modified, this will be stated in the response.

Expectation for required parameters:
1. `file_path` MUST be an absolute path; otherwise an error will be thrown.
2. `old_string` MUST be the exact literal text to replace (including all whitespace, indentation, newlines, and surrounding code etc.).
3. `new_string` MUST be the exact literal text to replace `old_string` with (also including all whitespace, indentation, newlines, and surrounding code etc.). Ensure the resulting code is correct and idiomatic.
4. NEVER escape `old_string` or `new_string`, that would break the exact literal text requirement.
**Important:** If ANY of the above are not satisfied, the tool will fail. CRITICAL for `old_string`: Must uniquely identify the single instance to change. Include at least 3 lines of context BEFORE and AFTER the target text, matching whitespace and indentation precisely. If this string matches multiple locations, or does not match exactly, the tool will fail.
**Multiple replacements:** Set `replace_all` to true when you want to replace every occurrence that matches `old_string`.

Edits a Jupyter notebook (.ipynb) safely at the cell level. Use this instead of edit or write_file for notebook cells. Supports replacing, inserting, and deleting cells. Always read the notebook first with read_file; then use the cell IDs shown in that output.

run_shell_command({ command: string, is_background?: boolean, timeout?: integer, description?: string, directory?: string })
monitor({ command: string, description?: string, max_events?: integer, idle_timeout_ms?: integer, directory?: string })

Executes a given shell command (as `bash -c <command>`) in a subprocess with optional timeout, ensuring proper handling and security measures.

IMPORTANT: This tool is for terminal operations like git, npm, docker, etc. DO NOT use it for file operations (reading, writing, editing, searching, finding files) - use the specialized tools for this instead.

**Usage notes**:
- The command argument is required.
- You can specify an optional timeout in milliseconds (up to 600000ms / 10 minutes). If not specified, commands will timeout after 120000ms (2 minutes). For longer commands, use `is_background: true` and observe the managed task instead of passing a larger timeout.
- It is very helpful if you write a clear, concise description of what this command does in 5-10 words.

- Avoid using run_shell_command with the `find`, `grep`, `cat`, `head`, `tail`, `sed`, `awk`, or `echo` commands, unless explicitly instructed or when these commands are truly necessary for the task. Instead, always prefer using the dedicated tools for these commands:
  - File search: Use glob (NOT find or ls)
  - Content search: Use grep_search (NOT grep or rg)
  - Read files: Use read_file (NOT cat/head/tail)
  - Edit files: Use edit (NOT sed/awk)
  - Write files: Use write_file (NOT echo >/cat <<EOF)
  - Communication: Output text directly (NOT echo/printf)
- **Shell argument quoting and special characters**: The active shell is Bash. When passing arguments that contain special characters (parentheses `()`, backticks ````, dollar signs `$`, backslashes `\`, semicolons `;`, pipes `|`, angle brackets `<>`, ampersands `&`, exclamation marks `!`, etc.), you MUST ensure they are properly quoted to prevent Bash from misinterpreting them as shell syntax:
  - **Single quotes** `'...'` pass everything literally, but cannot contain a literal single quote.
  - **ANSI-C quoting** `$'...'` supports escape sequences (e.g. `\n` for newline, `\'` for single quote) and is the safest approach for multi-line strings or strings with single quotes.
  - **Heredoc** is the most robust approach for large, multi-line text with mixed quotes:
    ```bash
    gh pr create --title "My Title" --body "$(cat <<'HEREDOC'
    Multi-line body with (parentheses), `backticks`, and 'single-quotes'.
    HEREDOC
    )"
    ```
  - NEVER use unescaped single quotes inside single-quoted strings (e.g. `'it\'s'` is wrong; use `$'it\'s'` or `"it's"` instead).
  - If unsure, prefer double-quoting arguments and escape inner double-quotes as `\"`.
- When issuing multiple commands:
  - If the commands are independent and can run in parallel, make multiple run_shell_command tool calls in a single message. For example, if you need to run "git status" and "git diff", send a single message with two run_shell_command tool calls in parallel.
  - If the commands depend on each other and must run sequentially, use a single run_shell_command call with '&&' to chain them together (e.g., `git add . && git commit -m "message" && git push`). For instance, if one operation must complete before another starts (like mkdir before cp, Write before run_shell_command for git operations, or git add before git commit), run these operations sequentially instead.
  - Use ';' only when you need to run commands sequentially but don't care if earlier commands fail.
  - DO NOT use newlines to separate commands (newlines are ok in quoted strings).
- Try to maintain your current working directory throughout the session by using absolute paths and avoiding usage of `cd`. You may use `cd` if the User explicitly requests it.
  <good-example>
  pytest /foo/bar/tests
  </good-example>
  <bad-example>
  cd /foo/bar && pytest tests
  </bad-example>

**Background vs Foreground Execution:**
- You should decide whether commands should run in background or foreground based on their nature:
- Use background execution (is_background: true) for:
  - Long-running development servers: `npm run start`, `npm run dev`, `yarn dev`, `bun run start`
  - Build watchers: `npm run watch`, `webpack --watch`
  - Database servers: `mongod`, `mysql`, `redis-server`
  - Web servers: `python -m http.server`, `php -S localhost:8000`
  - Any command expected to run indefinitely until manually stopped

  - Command is executed as a subprocess that leads its own process group. Command process group can be terminated as `kill -- -PGID` or signaled as `kill -s SIGNAL -- -PGID`.
  - To stop a background command started by this tool, use `task_stop` when a task id is available. Do not use broad process-name kills such as `kill $(pgrep node)`, `pkill node`, or `killall node`; use a specific PID or process group id where supported.
- Use foreground execution (is_background: false) for:
  - One-time commands: `ls`, `cat`, `grep`
  - Build commands: `npm run build`, `make`
  - Installation commands: `npm install`, `pip install`
  - Git operations: `git commit`, `git push`
  - Test runs: `npm test`, `pytest`

Starts a long-running shell command and streams its stdout/stderr as event notifications back to you.

Use this tool for:
- Watching log files: `tail -f /var/log/app.log`
- Monitoring build output: `npm run build --watch`
- Polling for state changes: `while true; do curl -s http://localhost:8080/health; sleep 1; done`
- Watching file changes: `fswatch -r ./src`

Each output line from the command becomes a notification event delivered to you. The monitor runs in the background — you can continue working while it streams events.

**Auto-stop:** The monitor automatically stops after max_events (default 1000) events or after idle_timeout_ms (default 5 minutes) of silence. The process is killed when the monitor stops.

**Do NOT use this tool for:**
- One-shot commands (use run_shell_command instead)
- Commands you need the full output from (use run_shell_command instead)
- Commands with no output (use run_shell_command with is_background: true instead)

Fast file pattern matching tool that works with any codebase size
- Supports glob patterns like "**/*.js" or "src/**/*.ts"
- Returns matching file paths sorted by modification time
- Use this tool when you need to find files by name patterns
- When you are doing an open ended search that may require multiple rounds of globbing and grepping, use the Agent tool instead
- You have the capability to call multiple tools in a single response. It is always better to speculatively perform multiple searches as a batch that are potentially useful.

A powerful search tool built on ripgrep

  Usage:
  - ALWAYS use Grep for search tasks. NEVER invoke `grep` or `rg` as a Bash command. The Grep tool has been optimized for correct permissions and access.
  - Supports full regex syntax (e.g., "log.*Error", "function\s+\w+")
  - Filter files with glob parameter (e.g., "*.js", "**/*.tsx")
  - Use Agent tool for open-ended searches requiring multiple rounds
  - Pattern syntax: Uses ripgrep (not grep) - special regex characters need escaping (use `interface\{\}` to find `interface{}` in Go code)

A powerful search tool for finding patterns in files

  Usage:
  - ALWAYS use Grep for search tasks. NEVER invoke `grep` or `rg` as a Bash command. The Grep tool has been optimized for correct permissions and access.
  - Supports full regex syntax (e.g., "log.*Error", "function\s+\w+")
  - Filter files with glob parameter (e.g., "*.js", "**/*.tsx")
  - Case-insensitive by default
  - Use Agent tool for open-ended searches requiring multiple rounds

Lists the names of files and subdirectories directly within a specified directory path. Can optionally ignore entries matching provided glob patterns.