Group chat with your agents, agents that message each other, and worktrees that set themselves up

Group chat

A group is one shared thread between you and 2 to 10 of your agents in a workspace. Groups sit in the sidebar under the sessions. The plus in that header makes one: a name, the members from your agents, and the member that answers when you address nobody. A group opens as a tab in the center, like a pull requests view.

• Who answers is explicit. Type @ in the message box to pick a member or everyone; a picked member becomes a chip. A message that mentions nobody says who it will go to, and goes to the group’s default member. Type / to send one of your prompts, as in a session: /review @Reviewer the queue.
• Each member answers from its own session, on its own runtime and model, so Prokop, Claude Code and Codex agents sit in the same group. A member sees everything said since it last spoke, labeled by author, and its finished reply is posted to the group as that member, with each tool call as one summary line. Its hidden session stays out of every session list; open it from the member’s menu.
• Members pass work on. A member can hand a distinct next stage to another member; the handoff shows as one line naming both, and the next member picks up from there.
• One permission setting for the whole group. The shield in the group’s message box applies to every member at once, and to members added later. Members’ approvals and questions are answered right under the thread.
• Working and stopping feel like a session. Your post shows the moment you send it. A member’s reply streams in as it is written. While members work, the send button is Stop and interrupts all of them; double Escape does the same, and Escape focuses the group’s own message box.
• On the phone a group is a tab in the Chat strip next to your sessions. On a narrow screen the members sit on their own row under the group’s name, with the ones that need you and the working ones first and the rest folded into a “+N” chip.

Agents message each other

An agent can send another of your agents a request, a question, a status, a result or an FYI, on Prokop, Claude Code and Codex alike. The recipient works on it as itself, in a conversation in its own home, with its own instructions, memory and skills, and keeps that conversation’s context across messages from the same sender. The sender keeps working; for a request or a question the answer comes back as a new message when the recipient’s turn ends.

An agent accepts messages only when its settings say so, and only agents with a home can. The new Messaging section in agent settings sets whether other agents may write to this agent and which agents it may write to. In the recipient’s home, conversations other agents started sit folded under From other agents in the sidebar. Messages stop after six hops from your own turn.

Delegation on every runtime

• One set of tools. Prokop, Claude Code and Codex sessions all get the same delegate_task, delegation_capabilities, task_status and task_cancel: hand a task to a role you defined, on its own runtime and model or on ones the agent picks, and get the result back. Prokop’s task tool is gone; delegate_task is its subagent tool now. An agent has them when it may spawn subagents, whatever its mode.
• Delegate without waiting. A delegated task returns at once by default and its result arrives later as a message, so the agent keeps working meanwhile. A task that stops for a question or an approval wakes its parent with a note, and the question shows on the session you are looking at, on every runtime.
• Sessions in their own worktrees. From one conversation an agent can start top-level sessions, each on a new branch in a new managed worktree with the repository’s setup applied, and keep talking to you while they work. These are ordinary sessions: open one, continue there, review the diff and merge. The agent hears when each finishes, with the branch, the worktree and the number of changed files. Three such sessions can run from one conversation at a time.
• Pick a runtime and model per task. Each agent’s Delegation targets setting says whether it may pick any enabled runtime, ask each time, run roles only as configured, or use specific runtimes without asking. A new agent defaults to Ask me each time: when it wants a runtime or model other than the role’s own, you get a question with Allow once, Allow for this agent, or Deny. Starting sessions in new worktrees asks too, unless the agent’s New sessions setting says otherwise.
• Subagents on Claude Code or Codex. A role pinned to one of them runs there when a Prokop session delegates to it, shows up live like any subagent, and hands its answer back the usual way.
• Subagent roles get MCP tools, the same ones as a primary agent; their own settings decide what they may do.
• Tasks survive retries and restarts. A retried delegation returns the task it already started instead of a second subagent, and a result that finished just as the server stopped is delivered when it comes back.

Worktrees that set themselves up

• A recipe in the repository. .prokop/worktree.json at the root says how a new managed worktree gets ready: ignored files such as .env copied from the main checkout, directories such as node_modules cloned without taking extra disk space, env and template files written with a port block reserved for that worktree ({{port}}, {{port+1}}) and a unique key for database or topic names ({{key}}). Every target has to be ignored by Git, so the worktree stays clean. A typo refuses creation with the line that is wrong.
• Commands run in the background. The file’s setup commands, bun install or creating a database, run in the new worktree after it is created, through your login shell. Because they come from the repository, they run only after you approve them once per repository; a changed file asks again. The worktree is usable while they run, and a failed command reports the step and the last lines of output.
• On the worktree row. Each worktree in the Worktrees panel shows where its setup stands: the running step, Run setup while the commands wait for approval, Retry and Log after a failure, the reserved port once ready. The checkout menu marks a worktree whose setup is still running, pending or failed.
• Agents know. A session in a worktree whose setup is still running, waiting or failed gets one note at the start of its turn, on every runtime, so it waits or tells you instead of running its own install.
• Teardown before removal. Removing a worktree stops a running setup, then runs the file’s teardown commands before the directory goes. Purging a removed worktree frees its port block.

Workspace

• Open a workspace together with others. A new button next to the workspace switcher lists the other workspaces. Pick one or more and Open together: you land in Overview, in the group that holds exactly those workspaces, created and named after them when there was none. Every session tab you had open comes along. The way back keeps its tabs too, and going from a workspace to Overview keeps them when the active group holds that workspace.
• Move files and folders in the Explorer. Drag an entry onto a folder, or onto the empty space below the tree for the workspace root. The row’s menu has Move to…, which asks for the destination and offers the folders matching what you type. Open editors follow a moved file.
• MCP tools load on demand. A workspace with more than ten MCP tools used to send every one of them, schema and all, on every step of a Prokop session. The agent now sees one tool_search tool with the deferred tools listed by name and server, loads the ones it needs by name or keyword, and those stay callable for the rest of the session. Claude Code and Codex sessions already worked this way.
• Notes from background work look like notes. When a background command finishes, or a delegated task finishes or needs an answer, the agent is woken with a message. It used to show as one of yours. It now shows as a single muted line under the conversation: the command or the task, how it ended, the output as a terminal chip.

Fixed

• Claude Code compaction no longer locks the conversation. Compacting a long Claude Code session could take longer than the two minutes Prokop waited, so it was cut off and the conversation refused every message after it. Compaction now gets ten minutes, and a compaction without a clear outcome is checked against Claude Code’s own history the next time you send.
• Claude Code turns no longer fail with “Unknown Claude content block”. Replies that used a server-side tool, such as web search, ended in that error and left the conversation stuck. Those parts are now skipped and the rest of the reply kept.
• Stopping a parent stops its delegated subagents. Stop on the parent, Stop on the child and task_cancel all end a running Prokop subagent now, and the parent gets a note that the task was interrupted.
• Stop a subagent from its own session. Opening a running subagent now shows a Stop control instead of a read-only note.
• The arrow keys visibly move through file and prompt suggestions again. The row picked with the arrows in the @ file list, the / prompt list, the group’s member list and the folder picker was drawn in a color almost identical to the list behind it in dark themes.

Update

Run this on the machine hosting your Prokop server:

prokop update