Mr. Mak Workspace: two desktop windows for driving CLI coding agents

The core idea: two windows, one task

The pitch in the first lines is your CLI agents, a visual Workspace, and access from your phone. The structure is two connected desktop windows.

Chats is where you give tasks to Codex, Claude Code, Antigravity, OpenCode or Kimi, and each conversation runs in a real CLI terminal with its own tab and saved history. Workspace is where you review the results, covering project pages, research, images, saved prompts and reports, with files, skills, MCP connections and settings sitting alongside your work.

The instruction is to keep the windows side by side, or minimize either one independently, so you can leave Chats in view while working in Blender, a game engine or your browser. That is the design rationale stated in one sentence, and it explains a lot. A terminal multiplexer shows you the agents, but it does not show you the images they produced, the reports they wrote or the research they gathered. A separate window for the output side is what makes the two halves usable together.

Version 0.5 adds the phone, connecting it to follow the same chats, send ideas and dictate messages while the agents keep working on the computer.

The project is MIT licensed, the primary language is Python with a TypeScript front end, the default branch is main, and the last push was on 2026-10-20. The recent releases are v0.5.2 on 2026-10-17, v0.5.1 on 2026-10-14 and v0.5.0 on 2026-10-08, whose title names mobile chats and voice input as the feature.

The Conversation view, and reading a transcript as messages

Claude Code and Codex chats have a Conversation or Terminal switch, and the Conversation view is the part that makes the tool worth having.

The view reads the CLI's own transcript and shows it as messages, with Markdown, images and recent tool activity. Its composer sends text, attachments and dictation to the same terminal, and Stop, bound to Esc, interrupts the agent. So the terminal is still the thing that runs, but you are not reading raw scrollback.

There is a deliberate rule about when you see which. A new chat opens in Terminal until it has a conversation, so folder-trust and sign-in questions are never hidden. That is a small decision with a good reason behind it. Those prompts are the ones where the CLI is asking whether it may proceed, and seeing them as raw text in a terminal is exactly the context in which you want to answer them.

Links to local files in a reply open a Workspace preview, resolved against the chat's folder. That is the link between the two windows: the agent mentions a file, and the review side opens it.

The permission menus are the other thing worth reading closely, because it is where a naive implementation would be dangerous. When the CLI asks for permission, the numbered menu at the bottom of the terminal appears as buttons. Before sending any key, Mr. Mak reads the screen again and checks that it is still the same prompt, so a late click cannot answer a newer question.

That check is the whole point. A permission prompt is a request to do something irreversible, and a click that lands a second late can approve the wrong action. Re-reading the screen and comparing the prompt before sending means the button reflects the question that is on screen now, not the one that was on screen when the button was drawn.

There is also a Read aloud option with the same local voices as the phone, and a Preparing audio message shown while the computer generates each part, which tells you the audio is generated locally rather than streamed from a service.

Small behaviours that come from using the thing every day

The rest of the chat feature list is a catalogue of things that only matter to someone who runs agents all day, and reading it is like watching a maintainer fix their own complaints.

Autocomplete commands: type / at the start of a message, or $ before a word in a Codex chat, to list that CLI's built-in commands plus project, user and plugin commands and skills. A command that opens a picker, such as /model, switches the chat to Terminal after it is sent, because a picker rendered inside the conversation view would be invisible.

Edit a sent message: in a Claude Code chat, the pencil on your message opens an editor, as with Esc Esc in Claude Code. Sending rewinds the conversation to before that message, with files not changed, and sends the edited text. After a rewind, including one made in the terminal, the view shows only the current branch. That last part matters, because a rewind in a terminal and a rewind in the UI have to agree, or you end up with a conversation whose history is a lie.

CLI events stay compact: background agent results, slash commands and their output appear as short events instead of raw tags, and a review's findings become a list with file links. You can choose Compact, Expanded or Hidden in chat options.

See what is still running: for Claude Code chats, a line above the composer counts the subagents and background terminal commands that are still working, and expanding it shows each agent's task and current step, each command and who started it, and how long each has been running. This is a direct answer to the question every agent user has, which is what is it doing right now.

Know the model: the status bar shows the model the chat last used, next to reasoning effort and permissions.

And Codex 0.163 chats are supported, with Mr. Mak starting Codex with --no-daemon when the installed version offers it, so every chat stays linked to its conversation, and a chat follows a rewind or a /new made in its terminal. The daemon is the interesting part of that: with a daemon in the way, the CLI no longer has a single process for the UI to observe, so the option to disable it is what makes the transcript readable at all.

Long chats, the handoff mechanism, and how projects are chosen

The project and long chat section describes a problem that arrives after a few days of use, which is that a conversation gets long and you want a new one that knows what came before.

New chat lists the folders you have worked in: the Workspace, projects opened in Claude Code, folders where Codex ran, and folders of earlier Mr. Mak chats. Favourites can be pinned to keep them at the top, history can filter by project, and the voice coordinator can open a chat in a project you name. A paired phone may only start a chat in a listed folder, never in an arbitrary path, which is a sensible limit given that the phone is a remote control for a machine that runs code.

The handoff mechanism is the answer to the long conversation problem. After a set number of your messages, 40 by default, with the chat options menu, a chat offers Summarize and continue. Mr. Mak asks the agent for a handoff, saves it in inbox/handoffs, and opens name · continued in the same folder with the same agent and settings. The new chat starts by reading that handoff. You can choose Later or Not for this chat to dismiss the offer.

So the context transfer is done by the agent itself rather than by a tool slicing the transcript. The agent writes the summary, which means the summary is in the agent's own voice and covers what that agent thought mattered, which is usually a better handoff than a mechanical truncation of the first N messages.

Groups are the other organisational feature. You can choose a group in New chat, or right-click a tab to create or join one. Group headers can be dragged, collapsed, renamed and coloured. Deleting a group keeps its chats, including those in History, and pinned tabs stay ahead of other tabs. Double-click a tab, or press F2, to rename its chat.

The Windows launcher is called Start Mr. Mak.cmd, and there is a setup.sh alongside it, which is the shape of a project that expects people to run it on more than one operating system.

The phone, and what each optional key buys you

The phone connection is a mobile web app you can add to your Home Screen, and it reaches the desktop through Tailscale. The README is clear that the agents keep running on the computer with their existing CLI accounts, so the phone is a remote control rather than a client that talks to the model directly.

Pairing is a deliberate flow: press the phone button on the computer, enable mobile access, scan the QR code and confirm the matching code on the desktop. The matching code is the security step, and it is the kind of thing that is easy to leave out and painful to add later.

After pairing once you reopen the same phone shortcut, and phone and desktop can show different chats while sharing the conversation. The features are: read replies, send follow-ups or images, open Workspace reports, speak a draft by recording and stopping to transcribe it with a review step before sending, enlarge shared images, play videos, reopen a report at its saved position, pull down from the top of the Workspace to refresh it, and use the back gesture to return to the previous screen instead of leaving the app on Chrome and Edge for Android. The Terminal view opens in Wrap mode on the phone so live text wraps to the screen and can be selected, with Fit and Actual still available.

The configuration side of this is entirely optional, and the .env.example file in the repository shows how optional it is:

# Optional voice connection. Terminal chats do not require this key.
OPENAI_API_KEY=

# Optional fal.ai generation account.
FAL_KEY=

# Optional coordinator model override; blank uses the Codex account default.
MRMAK_COORDINATOR_MODEL=

and further down, the dictation settings:

# Optional dictation overrides: local, openrouter, openai, or off.
# Blank selects free local Whisper; cloud providers require explicit selection.
# A saved choice in Phone settings / Speech-to-text takes precedence.
MRMAK_TRANSCRIBE_PROVIDER=
# Blank uses openai/gpt-4o-transcribe (OpenRouter) or gpt-4o-transcribe (OpenAI).
MRMAK_TRANSCRIBE_MODEL=

# Optional paths to an installed local Whisper Python and model directory.
MRMAK_WHISPER_PYTHON=
MRMAK_WHISPER_MODEL=

The default for the transcription provider is free local Whisper, with cloud providers requiring explicit selection, and a saved choice in the Phone settings taking precedence over the environment. There are also optional paths to a local Whisper Python and model directory for people who have them installed.

The most interesting detail in that file is the coordinator model. A blank value uses the Codex account default, which means the voice coordinator is not a separate model you have to pay for, it is the one the agent is already using.

How it is built, and the packaging of the skills

The repository is a Tauri application with a React front end, and the package.json shows how the two halves are wired.

The scripts split into a Vite front end and a desktop service. The dev script runs vite, the build script runs tsc -b and then vite build, and the lint script runs eslint over src. The desktop scripts run the service directly with node desktop/service/main.mjs, prepare it, build with tauri build, and run tauri dev. There is a separate AppImage build target, and a test target that runs node --test over the desktop service test files, plus a UI test script that chains eleven separate UI test files together, covering the core views, history, groups, conversation, theme, voice, desktop dictation, mobile and workspace editing.

The runtime dependencies are short, which is worth noting for an application with this much surface. There is React, the xterm terminal renderer with its fit and web links addons, and the Three.js type definitions. The xterm choice is the obvious one: the chats are real terminals, so the terminal renderer has to be a real terminal renderer.

The postinstall step is worth noticing. It runs npm --prefix desktop/service ci, so the desktop service has its own dependency tree, and then runs node scripts/fix-pty-permissions.mjs. A permission fix for a pseudo-terminal at install time is the kind of detail that only appears once you have shipped a desktop app that has to open terminals on several operating systems.

The Python in the repository is not incidental. The skills:pack script runs node scripts/run-python.mjs scripts/package_skills.py, and the test:template script checks the template and then runs the skills sync in check mode before the asset tests. So the creative skills the project ships are written in Python, packaged by a Python script, and synchronised into the application by a Node script, with a check mode in the test path so the two copies cannot drift apart silently.

The rest of the tree is a workspace layout with the usual pieces. There is a src-tauri/ directory for the Rust side of Tauri, a src/ directory for the React application, a desktop/ directory, an inbox/ directory which is where the handoffs are saved, a knowledge/ directory, a projects/ directory, a context/ directory, a processes/ directory, and a workspace/ directory. There is also an AGENTS.md and a CLAUDE.md at the root, a .mcp.json for MCP configuration, a .claude/ and .codex/ directory, and a .agents/ directory, which is the project's own agent configuration living alongside the tool that hosts agents.

Editorial conclusion

Adopt Mr. Mak if you drive coding agents through their command line interfaces and want a visual layer over them, especially the Conversation view, the permission menus and the handoff mechanism for long chats. Do not adopt it expecting to replace the agent, because every conversation runs as a real CLI in a terminal with its own account and sign-in. Before you turn on the voice or phone features, note that every one of them is optional and off by default, and that the mobile path depends on Tailscale reaching the machine the agents run on.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. witnesstodark/mr-mak-workspace on GitHub