Published on [Permalink]
Reading time: 7 minutes

Taming Claude Cowork session sprawl

Taming Claude Cowork session sprawl

Relentless Productivity™ has a dark side. The more capable your tools, the faster the work accumulates - and with Claude Cowork, that accumulation happens session by session, each one spawning its own entry in an ever-growing sidebar list that becomes harder to read by the day.

I know this from experience. My Cowork sidebar had grown to the point where I could no longer tell what was live, what was done and what was waiting. You can pin sessions. You can rename them. But there is no status indicator, no filtering and no way to see at a glance what needs your attention. Managing that list requires discipline, and discipline is not - let’s say - inherent in this particular operator.

So I went back and forth with Claude to work out a better approach.


The problem Cowork creates

Cowork is genuinely powerful. You give it access to a folder on your Mac, describe what you want in plain language and it runs - reading files, executing commands, writing output, co-ordinating sub-agents. It is Claude Code for knowledge workers rather than developers.

But that local-first architecture is also its limitation when it comes to session management.

When you use Claude via the browser at claude.ai, every conversation has a URL. claude.ai/chat/d156fdf3-... - a stable reference you can bookmark, share or link to from a project management tool. The session lives in the cloud and is accessible from anywhere.

Cowork sessions have none of that. They exist inside the Claude Desktop app, operating on files on your local machine. There is no URL. There is no way to reference a specific session from outside the app. The sidebar is the only index you have - and it auto-names sessions based on your first message rather than anything you choose to call them.

The strength of Cowork working exclusively on your local files is, in this respect, the downside.


What we built

The solution has three moving parts: a dedicated tracking directory, a Rocket Typist text expansion snippet and an end-of-session protocol.

Cowork sessions run inside Projects - a workspace layer that lets you attach specific folders to a session so Claude can read and write files within them. That folder attachment is where the session management system hooks in.

The Tracker directory

The first instinct was to attach a general ~/Documents/Claude/ folder to every Project, giving each session access to a shared log. That’s the wrong call.

Attaching a broad directory gives every Project session visibility into everything in that folder - files from other projects, notes, work in progress. Cowork is sandboxed by design, and for good reason. You don’t want a session working on your Acme Corporation board report to be able to read files from a personal task session, even accidentally.

The right approach is a dedicated ~/Documents/Claude/Tracker/ directory. It contains exactly two files - a session counter and a sessions log - and nothing else. When you attach it to a Project, you are giving that session a narrow, read-write window into tracking data only. No cross-contamination. No unintended exposure.

Create it once:


mkdir -p ~/Documents/Claude/Tracker

echo "0" > ~/Documents/Claude/Tracker/session_counter.txt

printf "| ID | Date | Project | Brief | Status | Outcome |\n|---|---|---|---|---|---|\n" > ~/Documents/Claude/Tracker/sessions.md

Every new Cowork Project gets two folder attachments: the project working directory and ~/Documents/Claude/Tracker/. That second attachment is the constant.

The Rocket Typist template

Rocket Typist is a macOS keystroke expansion tool. You define a short abbreviation - I use ;cw - and it expands to any block of text you choose when typed anywhere on your Mac, including in Cowork’s composer.

The template I push in at the start of every session:

Before anything else: read ~/Documents/Claude/Tracker/session_counter.txt, 

increment by 1, write back, append one row to 

~/Documents/Claude/Tracker/sessions.md (columns: ID / Date / Project / Brief / 

Status=Active / Outcome=blank). If ~/Documents/Claude/Tracker/ is not 

accessible, stop immediately and say: "TRACKER NOT MOUNTED — add 

~/Documents/Claude/Tracker/ to this Project before continuing." Then output: 

RENAME THIS SESSION TO: #N [one-line task summary] — then proceed with the task.



When I say "end session": update this session's row in 

~/Documents/Claude/Tracker/sessions.md — set Status to Done, write a 

one-sentence Outcome. Confirm: "Session #N closed."



Task:

You type ;cw, the template appears, you write your task on the final line and send.

Cowork reads the counter file, increments it, writes the new value back, appends a row to sessions.md and then - critically - outputs a rename string: RENAME THIS SESSION TO: #3 Review Acme Corporation Q2 capacity model. You copy that, right-click the session name in the sidebar, rename it, and the session is now findable by number for the rest of its life.

When you are done, you type “end session.” Cowork updates the sessions log row, sets Status to Done and writes a one-sentence outcome. The log becomes a running record of what was actually accomplished.

What the log looks like

| ID | Date       | Project     | Brief                          | Status | Outcome                                    |

|----|------------|-------------|--------------------------------|--------|--------------------------------------------|

| 1  | 2026-05-09 | Personal OS | Weekly Review protocol scan    | Done   | 16 open threads identified; rollup confirmed|

| 2  | 2026-05-09 | Acme Corp   | Q2 capacity model review       | Active |                                            |

| 3  | 2026-05-10 | Palim       | Scope sudoku whimsy feature    | Done   | Feature scoped; implementation deferred    |



A quick look at sessions.md tells you everything the Cowork sidebar cannot: what is live, what is closed and what was achieved.


When volume grows: the GitHub path

This system handles tens of sessions cleanly. If you are running dozens of concurrent workstreams - across projects, domains and time - the flat sessions log starts to show its limits.

The natural escalation is GitHub Projects, which gives you a proper Kanban board. Each session becomes a GitHub Issue. Columns map to session states: Backlog, Cowork Active, Claude Code Queue, Review, Done. You reference sessions by issue number (#42) rather than the counter above, and the Cowork session number goes into the issue body alongside the claude://cowork/new?q=...&folder=... deep link that re-opens a fresh session with the task context pre-loaded.

This also opens up the Claude Code integration path. Some tasks that start in Cowork are better finished in the terminal - file batch processing, code generation, scripted output. A GitHub Issue card flagged claude-code can be picked up by a small bridge script that pipes the task brief to claude --pipe, writes the result back as an issue comment and moves the card to Review. The Kanban becomes the dispatcher for both Cowork and Claude Code.

That is a bigger build. For most people the sessions log is enough.


A word on where this is going

Anthropic will work this out. The current Cowork interface was clearly built for focused, single-session work. As people use it at scale - running multiple projects, juggling parallel workstreams - the demand for better session state management will become impossible to ignore.

A status indicator on each session in the sidebar. A filter for Active versus Done. A Kanban or nested view. These are obvious features, and they will come.

Until then, a text expander, a counter file and a narrow Tracker directory get you most of the way there.


The setup described in this post requires a paid Claude plan (Pro, Max, Team or Enterprise) and the Claude Desktop app for macOS or Windows. Rocket Typist is a paid macOS app available at witt-software.com. GitHub Projects is free for public repositories and included in paid GitHub plans.


PS. This is another example of using AI tools not just to do work, but to diagnose problems with how you work - and then to build systematic approaches that make future performance more reliable. The conversation that produced this post was not “write me a blog post.” It was a back-and-forth that identified a real friction point, explored the constraints of the tool, and arrived at something that actually holds together.

The human is still required throughout. These are semi-sentient actors that will cheerfully proceed in the wrong direction if you do not hold them to account. The system only works because someone noticed the sessions were getting out of hand, cared enough to fix it and kept pushing until the solution was sound. That part does not automate.

✍️ Reply by email