How Do You Manage Claude Code Sessions?

What prompted this

I read shuntaka’s “Claude Code setup for a terminal-centric workflow” from Classmethod and wanted to compare it with my own workflow.

The article introduces a style that launches three tmux panes and keeps sessions around. Pull requests in the middle of review aren’t closed; they’re kept so you can revisit them later.

That made me reflect on how I’m handling things.

How I think about session management

The “keep sessions” camp (by shuntaka)

Run multiple Claude Code instances in three tmux panes
Keep sessions in the middle of review
Reattach to the same session with claude -r, go back with ESC ESC and fork

The upside is that your work log remains. You can later answer “what was I doing again?”

The “persist memory” camp

There’s also the option of persisting memory via an MCP like claude-mem. I don’t use it, but it’s a valid choice.

The “git push” camp (mine)

I have Claude summarize before context gets compressed and push to git.

Here’s what I write in CLAUDE.md:

At the end of a session: always run git add -A && git commit && git push.

The reason is simple: git is the more reliable place to keep things.

Claude Code sessions are volatile. Once context gets compressed, you don’t know what remains or how good the summary is. Git, on the other hand, persists for sure and other tools can reference it.

Document structure

To achieve “review later” via git, I keep the docs structured.

docs/claude/           # Claude用ガイド
  frontend.md          # フロントエンド開発
  backend.md           # バックエンドAPI開発
  appmanagement.md     # 管理画面フロント
  appmanagement-api.md # 管理画面API
  framework-common.md  # 共通フレームワーク
  docker-testing.md    # Dockerテスト環境
  ...

aidocs/appmanagement/  # タスク管理
  current-tasks.md     # 進行中のタスク
  completed-log.md     # 完了したタスクのログ

The key is being able to say “if you’re unsure, read this”.

If Claude gets stuck midway, telling it to read docs/claude/backend.md supplements the context. It’s more reliable to persist knowledge explicitly as files than to leave it implicitly inside a session.

Task management follows the same idea: write in current-tasks.md while in progress, then move entries to completed-log.md when done.

This solves the “no record of how we got here” problem. CLAUDE.md is best kept concise, but if it’s only bullet points that say “do X”, the reasons are lost. If you cram the details in, it quickly exceeds 1,000 lines and bloats the context.

So I split them:

CLAUDE.md: just the conclusions (keep it compact)
docs/: rationale, background, and details (have Claude read only when needed)

Because the reasoning per feature is captured in completed-log.md, you can later trace “why did we end up with this implementation?” It achieves the “revisit later” that the keep-sessions camp wants—via git.

Skill operations

I prepare Claude Code skills (slash commands) and use them like sub‑agents.

Skill	Description
`/build`	Frontend build
`/deploy-check`	Pre-deploy check
`/docker-copy`	Copy files to Docker
`/git-push`	Git commit & push
`/seed`	Seed test data
`/status`	Check dev environment status
`/test-e2e`	Run E2E tests (Playwright)
`/test-phpunit`	Run PHPUnit tests
`/test`	Run test command

Operational rules:

Only run skills; don’t allow file changes
Only send a completion notice
Do main work with the main agent

For example, when I want to run tests, I keep the main work going and have a sub‑agent run the tests, then just get notified when they finish. It keeps the context clean and makes use of the waiting time.

Skills can be composed. /deploy-check looks like this:

# デプロイ前チェック

ビルド → Docker送信 → テスト を一括実行する。

## 実行手順

1. `/build` - フロントエンドビルド
2. `/docker-copy` - Dockerへコピー
3. `/test` - PHPUnit + E2E テスト（並列）

## 使用タイミング

- 機能実装完了後
- プルリクエスト作成前
- 本番デプロイ前の最終確認

## 注意事項

- すべてのステップが成功することを確認してからデプロイする
- テストが失敗した場合は修正してから再実行

By calling multiple skills in order, you can run a one‑shot check. Writing down “when to use it” and “what to watch out for” helps Claude trigger it at the right moments.

Preventing accidents

Permission settings are a must. Don’t use --dangerously-skip-permissions.

The reason is straightforward: I once had a near‑miss where it tried to go to production.

Our Docker mirrors production, but its config files differ, so you can’t ship it as‑is. We had discussed “build for production, but do the deploy manually with a visual check”. Naturally I assumed it would stop at the build stage.

Later, in the same chat, I moved on to a different fix request. But the context still contained “build for production”, so from Claude’s perspective we were “working in the production environment”. I noticed and stopped it when it tried to edit a config file.

Had it been a separate chat, the permission settings and the “no production access” rule in CLAUDE.md would have triggered a warning. Because it was the same chat, the lingering context took precedence.

Claude Code sometimes doesn’t listen, and as the context grows it forgets instructions. If it believes it’s allowed, it just charges ahead.

That’s why, rather than focusing on “making the AI behave correctly”, I focus on “designing the system so mistakes don’t cause damage”.

Here’s what my workflow emphasizes:

Constrain with permissions
Let sub‑agents only run skills; forbid changes
Persist deliverables explicitly in git
Have it summarize before compression and then push

Takeaways

There’s shuntaka’s “keep sessions” workflow and my “git push” workflow. Neither is universally right; they simply serve different goals.

Keep sessions: reviewable work log
Git push: persist reliably and hand off to the next person

There’s no single answer. Find the approach that fits you.