DEV Community

UC Jung
UC Jung

Posted on

Claude Code CLI Practical Tips - 1. Using Background

Tip 1. Using Background

Why Use Background?

When working in the Claude Code CLI, you tend to handle everything in a single session — code implementation, test execution, file searches, refactoring. All of this accumulates in a single context window.

The problem is that the context from previous tasks influences the AI Agent's judgment on the next task. Prior implementation decisions, debugging attempts, and file explorations all color how the agent interprets your next instruction.

Background solves this. It runs tasks in a separate session, so the Main CLI's context stays clean.

Core Purpose: Context Isolation 

[Without Background — Single Session]

  Main CLI Context:
  ├── Implementation context (accumulates)
  ├── Test execution results (accumulates)
  ├── Debugging process (accumulates)    ← Context pollution
  └── Next task instruction
      → Judgment clouded by prior context

[With Background — Session Separation]

  Main CLI Context:
  ├── Core implementation work only      ← Clean state
  └── Next task instruction
      → Clear judgment without noise

  Background Session (separate):
  ├── Test execution
  ├── Lint checks
  └── Results saved to files → Referenced from Main
Enter fullscreen mode Exit fullscreen mode

How to Use It

Running a task in the background is simple. Just add "run this in the background" to your instruction.

> Run the following tasks in the background.
>
> 1. Run npm test and save results to ./reports/test-output.log
> 2. If any tests fail, summarize them in ./reports/test-failures.md
> 3. Print the result file paths when done
Enter fullscreen mode Exit fullscreen mode

When the CLI receives this instruction:

  1. A new session (Background) is created
  2. The instruction content is passed as a prompt to the Background session
  3. The Main CLI is immediately ready for your next input
  4. The Background session executes independently

Usage Examples

Offloading Tests to Background

> I've modified src/auth/auth.service.ts.
> Now run the tests in the background.
> - Execute npm test -- --coverage
> - Save results to ./reports/auth-test-result.md
> - Include the coverage report
>
> I'll continue editing the next file in this session.
Enter fullscreen mode Exit fullscreen mode

Offloading Code Review to Background

> Implementation is done.
> Run the following review in the background.
> - Review code in the src/payment/ directory
> - Check compliance against docs/api-convention.md
> - Save the review to ./reports/payment-review.md
Enter fullscreen mode Exit fullscreen mode

Offloading Build Verification to Background

> Refactoring is complete.
> Verify the build and type check in the background.
> - npm run build
> - npm run type-check
> - If there are errors, summarize them in ./reports/build-errors.md
Enter fullscreen mode Exit fullscreen mode

Ctrl + O — Viewing Background Execution History

To check the status and history of background tasks, press Ctrl + O.

What Ctrl + O shows:

① Background session list
   — All currently running background sessions

② The prompt Main CLI passed to the Background
   — See exactly how the CLI interpreted your instruction

③ Execution status of each session
   — In progress / Completed / Failed
Enter fullscreen mode Exit fullscreen mode

Item ② is particularly important.

When you say "run tests in the background," the Main CLI interprets this and generates a prompt to pass to the Background session. By pressing Ctrl + O, you can see exactly how the CLI understood your instruction.

[What you instructed]
> Run tests in the background and summarize the results

[Actual prompt passed — visible via Ctrl + O]
> "Run npm test in the project root directory.
>  Capture the output and save it to ./reports/test-output.log.
>  If any tests fail, create a summary at ./reports/test-failures.md
>  with the test name, error message, and file location."

→ See exactly what specific tasks your instruction was converted into
→ Spot misinterpretations immediately and correct them
Enter fullscreen mode Exit fullscreen mode

This is also a practical countermeasure for "Limitation ④ — The agent fills in gaps with inference and doesn't tell you." By checking the Background prompt, you can transparently see how the AI Agent interpreted your instruction.

Three Principles of Background Usage 

┌──────────────────────────────────────────────────────────┐
│       3 Principles of Background Usage                    │
├──────────────────────────────────────────────────────────┤
│                                                          │
│  1. Offload context-polluting tasks to Background        │
│     → Tests, linting, builds, reviews                    │
│                                                          │
│  2. Always instruct Background to save results to files  │
│     → Reference from Main via file paths                 │
│                                                          │
│  3. Build the habit of checking prompts with Ctrl + O    │
│     → Verify the CLI's interpretation matches intent     │
│                                                          │
└──────────────────────────────────────────────────────────┘
Enter fullscreen mode Exit fullscreen mode

Tasks Suited / Not Suited for Background

Suited Tasks Reason
Test execution Results are independent, no Main context needed
Linting / Type checking Simple execution + result collection
Code review Objective review without implementation bias (context isolation)
Build verification Simple pass/fail check
Document generation Can be written independently in a separate context
Not Suited Tasks Reason
Tasks requiring Main's conversation context Background doesn't have Main's chat history
Tasks that immediately follow prior results No context transfer — must re-explain from scratch
Interactive decision-making Background can't converse with the user

Top comments (0)