Claude Code CLI: Conversation Ops and Terminal Configuration

Claude Code CLI v2.1.91 offers over 40 built-in slash-commands for session configuration, reflection, management, context control, conversation operations, and terminal customization. The commands enable developers to manage working directories, model selection, effort levels, cost tracking, session branching, context visualization, and terminal themes.

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 . 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. 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 /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 terminalDiagnostics & 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 companionPermissions /permissions : Fine-grained allow & deny tool permission rules /sandbox : Configure settings to secure Claude terminal access and program execution rightsExtensions /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 pluginsIntegrations /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 SDKGroups and commands marked with ✅ were covered in an earlier article, while those with 🌀 are the focus of this article. /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. js 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. 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