Rambling Rows

Taming Claude Cowork session sprawl

Sat, 09 May 2026 19:27:00 +1000

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.

Very personal software

Mon, 04 May 2026 19:25:57 +1000

Geir Isene sat down at his computer last week and realised something unusual. Almost every program he touched - the window manager, the text editor, the file manager, the terminal, the email client, the calendar - was software he wrote himself. In a few weeks, with Claude Code as his engineering partner, he had replaced his entire desktop computing environment.

All of it command line. All of it terminal-native. All of it his.

Fair warning: the next bit gets technical in ways that will delight a certain kind of person and mean nothing to everyone else. Feel free to skim. The point lands either way.

The result is a two-layer stack he calls CHasm and Fe₂O₃. The first is pure x86_64 assembly - no system libraries, painting pixels directly. The second sits on top in Rust. Between them, they cover everything from the window manager to the screen locker to the text editor. The only surviving off-the-shelf programs are WeeChat for IRC and Firefox.

He put his account of the journey online this week. Worth reading for the vim story alone.

Vim - the modal text editor beloved by programmers and writers who’ve invested the muscle memory to use it - is not the kind of tool you replace. Geir had been using it since 2001. Twenty-five years. Every email, article, line of code and book went through vim. He thought he’d never replace it. He replaced it in seventy-two hours. His own editor, scribe, does everything he actually used in vim and none of what he didn’t. Twenty-five years of muscle memory rerouted in three days.

There’s a philosophical tradition this connects back to that predates software entirely. Before mass production, before village economies were fully established, people made their own tools. You forged your own knife, you shaped things to your hands rather than your hands to things. Then industrialisation made that inefficient and the skill slowly vanished.

Software industrialisation followed the same arc. General-purpose applications got powerful enough for most people most of the time, and the economics of building for yourself stopped making sense. Why write your own text editor when vim exists? Why write your own calendar when Google Calendar handles the whole family?

Geir’s story suggests the economics have flipped again.

It’s not that building your own tools has become trivial - Geir is technically sophisticated and the CHasm layer in pure assembly is genuinely serious work. But Claude Code dropped the cost dramatically. He would direct it between other tasks, it would build, he’d respond with the next requirement. The turnaround on features went from months of someone else’s roadmap to minutes.

And once you frame it that way, the efficiency question shifts. Yes, it took a few weeks of focused effort. But if you use those tools every day for the next ten years, that’s a different calculation. Especially when the alternative involves watching your tools get acquired, shut down, enshittified or quietly abandoned because they no longer fit a business model.

I’d be happy with the functionality of Microsoft Word 5.1 from 1989. Fast, functional, no subscription, no cloud sync, no feature bloat. Word 5.1 did everything most writers actually need. The only meaningful addition since then, for my purposes, is tables. The rest - collaboration features, AI integration, live cloud saving, the ribbon - is complexity that serves someone. It’s just often not me.

Geir calls his approach “design without committee.” No configurability for other users. No corner cases he’ll never hit. No documentation for users who don’t exist. The audience is one person, so decisions take seconds. Strip out the complexity of accommodating everyone else and what’s left is small, fast and exactly shaped.

Software exists on a spectrum from general to personal. At one end, operating systems and protocols. At the other, a text editor built to the precise dimensions of one person’s hands. Most commercial software clusters in the middle - general enough to sell to thousands, specific enough to feel useful. AI lowers the cost of the personal end so dramatically that the middle is no longer the obvious destination.

You probably won’t replace your whole desktop. But if you have one tool in your daily workflow that frustrates you - one thing you wish worked differently - the gap between “I wish this worked like this” and “it works like this” has never been smaller.

Geir calls himself a rabbit in spring. He’s having the time of his life.

So might you.

PS - Thanks to SmartFriend™ Peter Marks for sending me the original link. Peter is a man with too many hobbies. You can find him at blog.marxy.org.

Sources: