Run Claude Code alongside your editor

Working with an agent means moving between a request, a patch, and a test result. The editor’s job is to make those comparisons easy. You do not need a new working style to put them in one window.

Open your project in your editor, then start Claude Code in its integrated terminal:

claude --permission-mode default

That flag selects the manual approval mode: Claude asks before file edits and shell commands that no saved permission rule or organization setting already allows. The install lesson covers that setup and explains why this chapter pins it. Check the terminal’s working directory before launching. Some editors restore a terminal from an earlier workspace. Keep a second terminal available for the checks you run yourself, and use the editor’s source-control view to inspect changed and untracked files.

Keep the evidence within reach

Take the chapter’s worked task as the example: adding GET /healthz beside the existing /health in the payments service (the small TypeScript service this course uses as its running example), with HTTP tests for both in tests/health.test.ts. A useful arrangement is the agent conversation beside the changed route and its test, with test output below. When Claude reports that both endpoints work, you can look directly at the two requests in the test. When it proposes moving app construction out of src/index.ts into src/app.ts so the tests can import the app without starting the server, you can compare the moved code with the original. The same arrangement serves any change of your own: conversation, changed file, its test, output below.

That arrangement is useful even without an extension. Running the CLI in a terminal does not by itself promise native editor diff integration. For that, install the official Claude Code extension for VS Code, also available for Cursor, or use the JetBrains integration. Their documentation describes the supported connection and diff features.

The VS Code extension has its own panel; running claude in the integrated terminal still uses the separately installed CLI. If the extension does not appear after installation, reload the editor window. You can continue the chapter’s terminal workflow while sorting out the integration.

Give one worker responsibility for this patch

You may already use an assistant in your editor. Keep the tools that help you, but choose which one owns the current edit. Asking two agents to change the same uncommitted files makes the diff harder to attribute and the review harder to trust.

The decision is about the work in front of you. A small manual correction may be quicker to type. A coordinated route-and-test change may be worth delegating. In either case, the same files and checks are the evidence you review. The interface that produced the patch does not change the standard it must meet.

Close the chapter with a check

Before leaving this chapter, if you have the health-check patch, open tests/health.test.ts and explain why it would catch the loss of /health. If you are working with a change of your own, do the same with its regression test. Then locate the test output that tells you whether the project is ready to commit. If the full suite remains red, keep that fact in your handoff; a tidy editor layout should not make an unfinished check disappear.

There is one more piece of work to preserve: the reason behind a change. In this chapter’s example, the new route supports the monitor while the old route survives for its existing callers. Tomorrow, the code will still contain both, but a fresh conversation may not contain that decision. The next chapter follows what happens when you return to a project across sessions.