Skip to content

usage.md

Latest commit

 

History

History
173 lines (126 loc) · 40.1 KB

usage.md

File metadata and controls

173 lines (126 loc) · 40.1 KB
Raw

High Command usage guide

What High Command records

  • Messages to your session: deliveries to your main conversation from agent-team teammates, from subagents that message it by name, and from your other Claude Code sessions. A named subagent's message is recorded when its prompt holds a complete <agent-message> frame, both while the session is idle and during a turn (see Known limits). Task notifications, scheduled prompts, and your own Remote Control prompts are not recorded. Messages for local agents go to a separate lane for each agent.
  • Messages from your session: each plain-text SendMessage attempt that a model makes, with its reported result and a separate lane for each local sending agent. A send addressed by the ID of a listed local agent files under that agent's name, in one thread with its messages to you, unless another agent or peer shares the name. A send to the ID of an agent that is no longer listed files under that ID alone, in a thread of its own (see Known limits). A message to an agent that has no name, a message that another mod in your session sends, and a send by an agent that a mod started are not recorded (see Known limits). A structured message, such as a shutdown_request, shutdown_response, or plan_approval_response object, is not recorded either (see Known limits). A message to your session that a mod in the sender's session composed is recorded, as unverified sender unless the team harness wrote it to a verified mailbox.
  • Peer states: idle, interrupted, failed, ended, or shut down from teammates' notices, and busy, idle, offline, or another state word from the sessions Claude lists. A listed peer gets its state on its roster row once it has messages. When two listed rows share a name, the state on that peer's row may not be current (see Known limits).

A message that another mod consumes, or that you decline in an approval dialog, never reaches Claude, so High Command does not record it.

Unread and new messages

A message to your session is unread until you open its peer's thread, press Mark read in that thread, or press Read all in the pane or the band. Messages your session sends are never unread.

When you open a thread, the messages that were unread are marked new, and so is each message that arrives while the thread is open. The marks stay until you go back to the roster.

While unread messages wait, the status line under the prompt says high-command: {n} unread (retained). It is the mod's own line, so another mod's band cannot hide it. It clears when nothing is unread, and after /clear. After /branch, and after a /resume that brings an inbox back, it counts the unread messages of that inbox again (see Branches and resumes in Known limits). With managed settings or a Team or Enterprise sign-in, /branch starts empty, so the line clears then too. It counts the main inbox. With the agentLanesInBand option on, it also counts the unread messages of all agent lanes, as in high-command: 3 unread (retained) · 2 unread in agent lanes, or high-command: 2 unread in agent lanes when the main inbox has none.

Sender labels and marks

Each message to you carries one sender label. Claude Code's own record of where the message came from sets it. The message text can only lower it: a message that names a different teammate than the one that sent it is unverified sender.

Label Meaning
verified sender A teammate whose message the team harness wrote under that member's name.
local sender Another session or agent whose message Claude Code delivered. The label does not prove that the sender runs on this machine: Claude Code does not report the sender's host, so this can be a remote session. The name is that sender's claim.
unverified sender Everything else: a teammate in its own split pane, a named subagent that a mod started (see Known limits), a message that a mod in the sender's session wrote outside a verified team mailbox, a delivery Claude Code could not place, and a message that names a different teammate than the one that sent it.

A peer's row, the header of its thread, and /highcommand show the weakest label among its unread messages, so a newer message cannot hide the label of one you have not read. When none is unread, they show the label of its newest message to you. A peer you only sent messages to has no label.

A message is marked suspicious when its text matches a short fixed list of patterns: some wordings that tell an agent to ignore its earlier instructions, to change the permission mode, to run a download in a shell, or to read a credential file, and a long base64 block. The check ignores these invisible characters: Unicode format characters (category Cf, such as a zero-width space or a soft hyphen), the combining grapheme joiner U+034F, and the variation selectors U+FE00 to U+FE0F and U+E0100 to U+E01EF. It tests the text once with each of them read as a space and once with each removed, and marks the message when either test matches. Other invisible characters, look-alike letters from another alphabet, and one wording with these characters both inside a word and between two words can still avoid the mark. Other wording with the same aim, such as Ignore all preceding instructions, gets no mark, so a message without the mark can still try to steer an agent. The thread shows the mark on the message. A peer's roster row shows it while any unread message of that peer has it, and when its newest message to you has it. The mark hides no text, changes no delivery, and changes nothing that Claude reads, and /highcommand does not show it.

High Command never orders, highlights, or counts a message by a priority or urgency that its sender claims.

Surfaces

Surface Band Pane /highcommand
Terminal Yes Yes Yes
Desktop app Yes Yes Yes
VS Code panel No Yes Yes
Mobile app No Yes Yes
claude -p No No Yes, for the messages of that run only

Commands

Command Result
/highcommand Prints the summary: one row per peer with its unread count, the time of its latest message, its state, and the kind of its latest message. Runs at once, even during a turn.
/highcommand open Opens the pane on the first page of the main inbox roster. In claude -p, it explains that no pane can draw.

The pane

A roster or a thread reads from the top down:

  1. A location line, such as High Command › Main inbox or High Command › Main inbox › researcher. When the line has room, it ends with the dim hint ctrl+x tab or click for keys · esc to prompt.
  2. In a roster, the counts, such as 3 unread (retained) · 4 peers, and Read all. In a thread, the peer's last reported state, then the facts line with Show identity and Mark read.
  3. A dim line that says when the capture window began, that it covers this conversation only, and that the order is observation order. After /clear, and after a /resume or a /fork copy that brings no inbox back, it also says that earlier history was not restored. A conversation that you moved to the background (/background, /bg, or ← on an empty prompt) runs in a new process, so its line says this too. In a branch, the line starts with the time of /branch and the count of messages the branch kept from the parent conversation, as in Branched 13:04 · 12 messages from the parent conversation · since 12:04 · observation order. With managed settings or a Team or Enterprise sign-in, a branch starts empty and its line says that earlier history was not restored, but a new process does not say it (see Managed settings and Team or Enterprise sign-ins in Known limits).
  4. A notice that counts the messages dropped for good, when there are any.
  5. The peer rows, or the thread's messages, then a page row when there is more than one page.
  6. In a roster, the agent lanes.
  7. The dim order note, Order: observation time. Counts cover retained messages.

The roster lists peers you received messages from or tried to message: peers with unread messages first, then the peer with the most recent message. In a pane of 90 columns or more, each row is one line of fixed columns under a dim header: the peer, the unread count, the time of the latest message, the sender level, the peer's last reported state with its time, and the latest message. Any suspicious and (not delivered) marks start the latest message. A narrower pane gives each row two lines (see Narrow panes in Known limits). suspicious shows in your theme's warning color, and (not delivered) in its error color. Sender labels, unverified sender too, are plain text: in tmux, each teammate runs in its own pane, so every message can be unverified sender, and a color there would hide a real suspicious mark. The words stay, so a terminal without color loses nothing. On a row with nothing unread, the time, the state, and the message summary are dim. The arrow, the kind of message, and the marks are not. Press a peer, or its digit, to open its thread. The digits follow the roster order, so they move when a new message arrives. Rows past the ninth have no digit. A roster page shows up to 50 peers, with Previous peers and More peers on one row. When long names and messages would pass Claude Code's drawing limit, a page shows fewer, and a dim line says how many peers moved to the next page.

A thread starts with Back, the peer's last reported state with its source, and a facts line: the word Sender with the sender level, such as Sender unverified, the count of kept messages, the count of new messages, and the page. Show identity and Mark read follow the facts, or move to a line of their own when the line does not fit. A thread shows up to 20 messages per page with that peer, newest first. When long messages would pass the drawing limit, a thread page shows fewer, and a dim line says how many moved to the next page. Each message starts with new while it is new, its time, ← for a message to you or → for a send attempt, and its kind: message, finished, failed, or send attempted. The sender label and any suspicious mark follow. A dim day line comes before the first message of an earlier day. The summary shows only when the sender wrote one that differs from the first line of the message. A long message shows its first 2,000 characters and says how many more are in the transcript. Newer and Older page through the kept messages, on one row with the page number and the count of messages on other pages.

A send shows send attempted with the recipient and text that High Command observed. Its reported send result shows on a line of its own, in the error color when the send was not delivered. A dim note above the first send of a page says that sends show observed text and that a reported result is not a receipt. Show send details shows the refusal reason, up to 2,000 characters. When available, it also shows the core lines: the recipient, text, and queue outcome that Claude Code itself received for the latest call. A dim note above the core lines says that this evidence covers only the latest traced call. It does not prove that the recipient read the message. Hide send details closes them again. /highcommand labels sends as attempts.

Show identity opens the peer's full name as a level of its own, 1,000 characters per part. That level shows only the location line, the part number with the name's length in characters, and the part. A name of more than one part adds Previous identity part and Next identity part. Back returns to the thread.

Both ways to open the pane show the main inbox, even while an agent transcript is in view. Once opened, the pane keeps the lane you pick and does not follow the agent transcript you view. The Agent lanes section under a roster has Main inbox and one button per agent, and ▸ marks the lane on screen. Press an agent's button to see its lane, and Main inbox or Back to return to the main conversation. A button shows the agent's name, or its ID when the agent has no name or a name of only spaces or invisible characters, and adds the ID when two agents on the page share a name. Agent lane counts and read actions are separate, and each agent's button shows its lane's unread count. The section shows up to 10 agents per page: each local agent and each agent with a lane. When long agent names would pass the drawing limit, a page shows fewer, and a dim line says how many agents moved to the next page. Agent status shows each agent's status (see Known limits).

Back goes up one level: from a peer's identity to its thread, from a thread to the roster page that now shows that peer, and from an agent lane to the main inbox. Opening a thread marks the peer read, which can move its row to a later page.

The band

While unread messages wait, the band shows the total and up to three peers, the most recent first. When its row has room, the row ends with the dim hint ctrl+x tab to choose. Press Ctrl+X, then Tab, to give the band the keyboard. Then Tab moves between its buttons, Enter presses one, and Esc gives the keyboard back to the prompt. Open shows the first page of the main inbox roster, even while an agent transcript is visible. The pane opens without the keyboard, because the band holds it: press Ctrl+X, then Tab, until its border is focused, or click the pane to give it the keys. Read all clears every unread count. Hide puts the band away until a newer message arrives; it marks nothing read, and the status line keeps the count. The band gives way to Claude Code's surveys.

By default, the band counts the main inbox only. With the agentLanesInBand option on, it also shows the unread count of all agent lanes, as in High Command · 3 unread (retained) · 2 unread in agent lanes, and it also shows while only agent lanes have unread messages. Read all then also marks every agent lane read. Hide then holds until a newer message arrives in the main inbox or in an agent lane, and the band comes back with both counts. Open still shows the main inbox: press an agent's button in the pane to read its lane.

Keys

Key Where Action
Ctrl+X, then Tab Anywhere Move the keyboard to the band or the pane. This is Claude Code's own focus chord.
Tab Band or pane Move to the next button
Enter Band or pane Press the button that has focus
o Band Open the pane
r Band or pane roster Read all
h Band Hide the band until a newer message arrives
1-9 Pane roster Open a thread
p, n Pane roster Previous or next page of peers
m Pane roster Main inbox
b Pane thread, identity, or agent lane Back up one level
i Pane thread Show identity
r Pane thread Mark read, only while Mark read is visible
p, n Pane thread Newer or older page
p, n Pane identity Previous or next part of the name
Esc Band or pane Give the keyboard back to the prompt

In the terminal, the pane shows each letter and digit key before its button's label, as in r: Read all. The agent buttons, the agent pages, Agent status, and Show send details have no key: press Tab to reach them, or click them. When the pane's location line has room, it ends with the dim hint ctrl+x tab or click for keys · esc to prompt.

Release Ctrl before you press Tab, because many terminals read Ctrl+Tab as next tab. In Emacs terminals, Ctrl+X goes to Emacs: click the band, run /highcommand open, or rebind abovePrompt:focus with /keybindings.

Letter and digit keys work only while the band or the pane has the keyboard. Focus moves through each band button before it reaches the pane, so press Ctrl+X, then Tab, until the pane border shows focus. /highcommand open opens the pane directly. Opening a thread marks its kept messages read, so r works in a thread only when Mark read shows again, after that peer sends a new message.

Options

Set options in /config, or under pluginConfigs["high-command@high-command"].options in ~/.claude/settings.json. For a --plugin-dir load, the key is high-command@inline.

Option Default Effect
agentLanesInBand false Adds the unread count of all agent lanes to the band and the status line, as described in The band. Off, they count the main inbox only.

A change takes effect at once: Claude Code reloads the mod with the new values. The reload keeps the current inbox, but it drops the inboxes that the mod kept for /resume (see Reloads in Known limits).

Known limits

The first list holds the limits you can hit in daily use. The second list holds rare cases: size caps, unusual names and frames, changes by other mods, and display gaps.

Limits in daily use

  • Agent lanes: messages that local agents send and receive go to a separate lane for each agent. Each lane has its own counts and read marks. The pane shows each lane's unread count on that agent's button, and /highcommand lists the counts apart from the main inbox. By default, the band, the status line, and Hide cover the main inbox only, so an unread message in an agent lane does not show there. The agentLanesInBand option adds the unread count of all agent lanes to the band and the status line. A message between your main conversation and a local agent can show twice, once in the main inbox and once in that agent's lane. The lane copy of a message from your main conversation never counts as unread. High Command does not see messages between teammates that run in their own split panes.
  • Local agent status: in the pane, Agent status comes after the agent buttons, on their last row when it fits. It shows the status of each agent on the page, with a dim note that a roster snapshot does not confirm that an agent still runs. That status, and the one in /highcommand, names its source. A roster snapshot status comes from Claude Code's local agent list. High Command reads that list when you open the pane or run /highcommand, when an agent starts, and when an agent ends a turn. Between reads, the status can be old. When two reads overlap, the older one can bring back an agent that the newer one removed. Open the pane or run /highcommand again after agent activity settles. A lifecycle observation says how an agent's last turn ended, such as turn answered or turn error. When the list does not hold an agent that ended a turn, an open pane shows that observation as the agent's status until the next read of the list. It describes a finished turn, so it does not prove that the agent still runs. A teammate in its own split pane can keep its last status after it crashes. /highcommand lists up to 100 local agents. The pane pages through all of them, up to 10 at a time.
  • Peer states: a peer's roster row shows only states from teammates' notices and ListAgents results, never the local agent status. A state is the last one reported, with its time, so it does not prove that the peer is in that state now. When two rows of one ListAgents result have the same name, High Command cannot tell whose state is whose. When the result lists its rows as data, High Command takes no state for that name, so a state recorded earlier, such as offline, stays on that peer's row. When the result holds only the printed listing, that name gets the state of the last such row that has one.
  • Send results: a send shows the recipient and text that High Command observed, and the result reported back to High Command. Show send details shows what Claude Code itself received, which another mod may have changed, and whether Claude Code queued the message. When a mod answers the send itself, Send details cannot show this. When a mod sends the message more than once, Send details covers only one of those sends. A refused send shows the first 120 characters of the reason, on one line, in its reported send result. Send details keeps up to 2,000 characters of the reason, with its line breaks, and says when it was cut. A queued message is not proof that the peer read it.
  • Structured sends: Claude Code passes only plain-text SendMessage messages to High Command. A SendMessage whose message is a shutdown_request, shutdown_response, or plan_approval_response object does not reach it. Neither its attempt nor its result appears in the main inbox, an agent lane, or /highcommand. Check the transcript for these sends.
  • Branches and resumes: High Command starts empty in each new Claude Code process. /branch keeps the inbox as it stood at the branch point: the messages of the main inbox and of each agent lane, the peers and their reply addresses, the read marks, and Hide. New messages go on top. A message you had not read stays unread, with its sender label and any suspicious mark, so the band and the status line count it again. The pane says when you branched and how many messages came from the parent conversation, and /highcommand says the same. That count covers the main inbox and the agent lanes. A branch of a branch also keeps the messages of each conversation before it, and /highcommand counts those conversations. /resume of a conversation that ended in the same process brings back its inbox as it was when it ended. The process keeps the inboxes of the 10 conversations that ended last, so a resume of an older one starts empty. /resume never keeps the inbox of the conversation you leave. A /resume of any other conversation, such as one from an earlier process in the /resume list, starts empty, with no agent lanes, as after /clear. The open thread and the roster page start over, in the main inbox and in each agent lane, and so does the lane you picked. With managed settings or a Team or Enterprise sign-in, /branch starts empty instead (see Managed settings and Team or Enterprise sign-ins).
  • Reloads: a reload of the mod keeps the current inbox, but it drops every inbox kept for /resume. A /resume after the reload then starts empty, also for a conversation that ended in this process. Claude Code reloads the mod when you change one of its options, and when it loads new code of the mod, as at /reload-plugins after an update. /branch still keeps the inbox after a reload. With managed settings or a Team or Enterprise sign-in, a reload that no slash command and no /config change causes, before High Command takes a /resume and writes its copy, drops the inbox that it would bring back (see Managed settings and Team or Enterprise sign-ins).
  • No earlier history: /clear starts an empty inbox. High Command keeps the inboxes in the memory of the Claude Code process only, never on disk. So claude --resume in a new process, --fork-session, and a /fork copy, which runs in a process of its own, start empty, even when the conversation that Claude reads holds earlier messages. A conversation that you move to the background, with /background, /bg, or the left arrow (←) on an empty prompt, starts empty too: Claude Code continues it in a new process, as after claude --resume. The pane and /highcommand say when the capture window began. After /clear, and in each of these cases, they also say that earlier history was not restored. With managed settings or a Team or Enterprise sign-in, a new process does not say this (see the next item).
  • Managed settings and Team or Enterprise sign-ins: with managed settings on the machine, or with a Team or Enterprise sign-in, Claude Code does not pass classic.SessionStart to installed mods. High Command then reads the session ID at once after a /clear, /branch, or in-app /resume, then every 500 ms for up to 5 minutes, and at each of its events, such as a message, a send, the end of a turn, /highcommand, a press, or a drawing of the band or the pane. It also reads the session ID before each slash command, such as /reload-plugins or /config, and before each change in /config. At the first read that names the new conversation, it takes the switch. Before a slash command or a /config change goes on, High Command takes the switch this way and waits until its copy of the inbox is written, also when a drawing of the band or the pane took the switch first. So a reload that the command or the change causes keeps the inbox. Only a reload of the mod that no slash command and no /config change causes, such as one after an edit of a settings file, can come before that copy is written. That reload drops the inbox that /resume would bring back. /clear starts an empty inbox, and /resume brings back an inbox that this process kept, as described in Branches and resumes. There High Command cannot tell /branch from a /resume of a conversation from another process, so /branch starts empty, with no agent lanes, and the pane and /highcommand say that earlier history was not restored. The parent conversation keeps its own inbox, and a /resume of it brings that inbox back. A new process, such as claude --resume, --fork-session, a /fork copy, or a conversation in the background, starts empty too, but there the pane and /highcommand do not say that earlier history was not restored.
  • Display only: High Command changes nothing that Claude reads. Its inbox leaves out idle notices with no content, but Claude still reads them, so the inbox saves no model turns or tokens.

Rare cases

  • Retained history: the main inbox and each agent lane keep 200 messages in all and 50 per peer. A peer past 50 messages loses its own oldest ones first. Past 200 in all, the oldest messages drop. A notice counts the messages dropped for good, and unread counts cover kept messages only. A thread shows up to 20 messages per page, fewer when they are long. Older and Newer page through every kept message. Opening a thread marks all of that peer's kept messages read, also those on other pages. The roster shows up to 50 peers per page, fewer when their names and messages are long. Peer states are kept for the 100 peers reported most recently. A message keeps its first 2,000 characters, and its thread says how many more are in the transcript. An agent lane also has a cap in characters (see Space for agent lanes).

  • Sends by mod-started agents: Claude Code reports a send by an agent that a mod started as that mod's send. High Command records no mod's sends, so these sends do not show in that agent's lane or in /highcommand. Messages to that agent still show in its lane. Its messages to your main conversation or to another local agent still show in the main inbox or in that agent's lane.

  • Space for agent lanes: High Command saves all agent lanes of a conversation as one value. Claude Code 2.1.296 refuses a saved value over 4,194,304 characters of JSON text, so High Command caps the lanes below that size:

    • Each agent lane keeps at most 500,000 characters of saved message data. 200 messages of 2,000 characters fit. Sends with long Send details, and text with many line breaks or quotation marks, take more space, so such a lane can keep fewer than 200 messages. Past its cap, a lane drops its own oldest messages first.
    • All agent lanes together keep at most 4,000,000 characters, about eight full lanes of 2,000-character messages. Past that, the oldest messages of all lanes drop. High Command compares lanes by observation time. Each lane still drops its messages in recording sequence and keeps its newest message.

    New agent messages keep recording, and each lane's notice counts the messages it dropped for good. Because each lane keeps its newest message and its peer states, a conversation with very many agent lanes can still reach Claude Code's limit: about 1,800 lanes whose newest message has 2,000 characters, or fewer when those messages are sends with long Send details. High Command then keeps no change that would pass it. A new agent message still reaches its recipient unchanged. High Command does not record it and writes high-command: session.receive: could not record a delivery ... or high-command: session.send: could not record a message to ..., and a new peer state in a lane writes high-command: tool.call ListAgents: could not record peer states: .... A lane button can also fail with a high-command: ui.press: ... toast. Read the missed messages in that agent's transcript. The main inbox is saved apart and keeps recording. /clear starts a new capture window, which empties every lane and the main inbox. /branch keeps the parent conversation's lanes, except with managed settings or a Team or Enterprise sign-in. /resume brings back lanes only with a kept inbox, and otherwise starts with none (see Branches and resumes).

  • Peer names: High Command tells peers apart by name. Two senders with the same name share one roster row. Names that differ only in spacing or in invisible characters count as one name. A name longer than 60 characters shows cut, with a short code that keeps cut names apart. Show identity in the thread shows the full name. A send that Claude addresses by the ID of a listed local agent files under that agent's name, on one row with the agent's messages to you. These sends count toward that name's 50 kept messages, so many sends can push out an unread message. The send files under name [ID], on a row of its own, when another listed local agent has the same name or a peer of that name has another session's address. A name that holds only spacing and invisible characters files under [ID]. High Command reads the local agent list at each send. Claude Code drops an agent from that list when the agent ends or some time later. A send to the ID of an agent that is no longer listed files under that ID alone, on a row of its own, apart from the agent's messages to you.

  • Sends changed by earlier mods: a mod that runs before High Command can change a send's recipient and text. High Command then shows the changed recipient and text, and files the send under the changed recipient. It cannot show what Claude first wrote. Check the SendMessage call in the transcript.

  • Subagent messages: Claude Code does not say whether a mod started or wrote a named subagent's message to your main conversation. High Command reads the local agent list when such a message arrives. The message is unverified sender when a mod started every listed agent whose name or ID its frame gives. Otherwise it is local sender: also when a mod wrote it from an agent that the model started, when its frames name several senders, and when the list cannot be read. Agents that left the list do not count, so a message from a model-started agent that already ended is unverified sender while a mod-started agent of the same name is listed. High Command counts such a message only when the prompt that reaches it holds a complete <agent-message> frame and no frame of another kind. A mod that runs after High Command can remove that frame. High Command then files the changed text under the one name that the frames gave, or under unnamed peer when they gave none or several. A sender name in the changed text, such as a from field, does not change this.

  • Damaged frames: Claude Code can wrap a peer's message in a frame, such as <teammate-message>, whose attributes name the sender. A malformed attribute, a frame with no closing tag, or text beside complete frames makes High Command write an incomplete frame parsing line. A complete frame with a malformed attribute keeps the attributes that High Command could read, such as the sender name and summary. The sender label rules still apply to that name. A frame with no closing tag, and text beside complete frames, become a message from the delivery's sender, or from unnamed peer, without frame attributes. Check the transcript for the original frame. A delivery that Claude Code could not place is recorded only when it holds a complete frame.

  • Messages and presses during a switch: High Command keeps the inbox of each conversation in the memory of the Claude Code process and shows the current one. A message that arrives while /branch, /resume, or /clear runs goes to the conversation that was current when it arrived. During /branch that is the parent, so the branch gets the message too, unless its delivery to Claude ends only after the branch began: then it stays with the parent. With managed settings or a Team or Enterprise sign-in, the branch starts empty, so such a message stays with the parent only. Read all, Mark read, Hide, and an opened thread cover only the messages that the pane or the band showed when you pressed. A press on a drawing of another conversation, such as one drawn before a switch, does nothing.

  • Display order: the pane and /highcommand sort messages by observation time, the time High Command first saw each one, before other mods and Claude Code handled it. That is not always the order in which messages reached Claude. Read marks, Hide, which messages drop first within the main inbox or one agent lane, and the label of a peer with nothing unread follow recording sequence, the order in which High Command finished recording messages. Between agent lanes, drops follow observation time (see Space for agent lanes).

  • Narrow panes: below 90 columns, a roster row takes two lines, so the roster is twice as tall. The first line holds the name, the unread count, the time, and the state, and a narrow pane cuts the state first. The second line starts with the marks: the sender label, any suspicious mark, and any (not delivered) mark. They wrap and are never cut. The latest message follows them, cut at its end, or takes a line of its own when the marks leave it fewer than 20 columns. From 90 columns, each row is one line of fixed columns: a name wider than 16 columns shows its start and its end, as in integrat…r-alpha, and a message from another day shows only its date. When two names would show the same label, each shows a shorter cut and a 4-digit code from its full name, as in inte…nner [f2e3] and inte…nner [e886]. A label comes from its own name, so a new look-alike can switch a name to its code but cannot take its label. Names that also share the code are numbered in name order, and only those numbers can move to another peer. The state column widens to the longest state on the page but leaves the message at least 27 columns, so a state is cut only when the row is full. Those columns hold the suspicious and (not delivered) marks, so a cut never reaches them. A thread shows the name up to 60 characters, the full state, and the time of day. The column header scrolls away on a long roster. The location line leaves out its key hint when the hint does not fit, and a thread moves Show identity and Mark read to a line of their own.

  • Band space: when other mods draw a lot in the area above the prompt, the band first leaves out its key hint, then shrinks to the count and Open. When even that would pass Claude Code's limits for one drawing, the band does not show. The status line still counts unread messages. The band also gives way while a Claude Code survey shows.

  • Summary as a list: when a peer name holds a | after an odd number of backslashes, /highcommand prints a list instead of a table. A table cell cannot show such a name as written.

  • Cut-off failure lines: when High Command cannot record a send, the high-command: session.send: could not record a message to ... line names the recipient before the cause. The terminal draws the first 2,000 characters of a line. Remote surfaces and the debug log keep 10,000. A very long recipient can push the cause past that point. The SendMessage result in the transcript still says whether the message was queued.

Troubleshooting

Sign Cause and fix
No /highcommand command The mod did not load. Run claude plugin test in an empty folder to check that mods can load, and check that the mods active line in /plugin names high-command. A high-command: session.start: could not register /highcommand: ... line names the cause.
claude plugin test says hooks modules are turned off Mods cannot load. turned off here means a setting or your organization's policy blocks them. turned off in this process means installed mods are off: start claude once with network access, then run the check again. If the message stays, installed mods are turned off remotely, and no setting on your machine turns them back on.
high-command: session.receive: could not record a delivery ..., or the same line with prompt.submit for a subagent's message A message reached Claude, but High Command could not record it. The message itself is safe. A repeat of the same failure goes to the debug log only (claude --debug).
high-command: ui.render (Pane): ... in the pane The pane could not draw. The line names the cause.
A high-command: ui.press: ... toast A button could not finish its work. The toast names the button's action and the cause.
unnamed peer rows The delivery named no sender. With claude --debug, each one writes high-command: session.receive: a <kind> delivery named no sender, or the same line with prompt.submit for a subagent's message. Please report it with your Claude Code version.
unverified sender on every teammate Your teammates run in split panes, which write through a file that Claude Code cannot check.
A debug line names high-command after you decline a message Claude Code reports the declined delivery under each mod that passed it on. High Command records nothing for that message.
States never appear Peer states come from teammates' notices and from ListAgents results that Claude gets. Local agent status is separate: open the pane or run /highcommand to read it again.
high-command: <event>: could not update the view: ... High Command could not write its copy of the inbox to $.state. The pane and the band still show the inbox, but they can draw a change late, and a reload of the mod can bring back an older copy. The line names the cause.
high-command: <event>: could not take back the inbox: ..., or high-command: <event>: could not read the session id: ... After a reload of the mod, High Command could not read its copy of the inbox in $.state, or could not tell which session it belongs to. Until it can, it records nothing and never writes over the copy, and it tries again at the next event. Messages that arrive meanwhile still reach Claude, but High Command does not list them. With managed settings or a Team or Enterprise sign-in, the session ID line can also come during a /clear, /branch, or in-app /resume. Until a read of the session ID works, High Command cannot tell that the conversation changed. It then shows the conversation that ended, and it files the messages and sends that arrive meanwhile under that conversation, so the new conversation does not show them. They still reach Claude. The line names the cause.
high-command: <event>: the agent lanes of 1.2.2 pass the space of one saved value, ... After an update from 1.2.2, the agent lanes and their Hide marks together were too large for one saved value. High Command kept the lanes and dropped their Hide marks, so the band can count those lanes again. When even the lanes alone were too large, the line also counts the lanes it dropped, those whose newest message was oldest.
high-command: <event>: could not update the status line: ... The status line could not be updated, so it can show an old count. The line names the cause. High Command tries again at the next message to or from your session, and when you open a thread or press Mark read or Read all.
A harmless message is marked suspicious The mark comes from a short fixed list of patterns, so a normal message can match. Nothing is blocked.
The band is gone but the status line still counts messages You pressed Hide, and the band comes back with the next message. The band also gives way while a Claude Code survey shows, and when another mod draws so much below it that the band would pass Claude Code's limits for one drawing. In each case /highcommand open shows the pane.