Coding Sessions

A session is a live conversation with Claude Code running inside a cloud VM. You send messages, Claude writes code, and you see changes in real time.

Starting a Session

There are two ways to start a session:

• Create a task with a prompt. The session starts automatically.
• Open an existing task and start a new session from the task detail view.

When a session starts, Wallfacer boots a VM from your environment's snapshot or from a fresh image (which takes longer if no snapshot exists). Once the VM is ready, Claude Code is running and waiting for instructions.

Waiting for a Machine

Sometimes no machine is free when a session asks for one. The session parks in a waiting state and retries on its own, and the chat screen says so rather than showing an indefinite "Starting up". A Waiting for a machine notice sits above the composer with a counter for how long the wait has run, and explains that every machine is busy and the session starts as soon as one frees up.

The composer stays live while you wait, because queueing more instructions is legitimate. Anything you send reads Queued -- waiting for a machine and delivers in order once the session starts.

If capacity never frees up, the platform stops retrying rather than leaving the session queued forever. It retries for over an hour and then closes the session, and a wait that outlives any retry schedule is closed by a sweep instead. Either way the notice becomes No machine was available with the platform's own explanation of what happened, and you get a notification.

Both of those closes are resumable. Send another message and the session starts a fresh attempt.

The Chat Interface

Type messages in the input at the bottom of the screen. Cmd+Enter (or Enter) to send.

Claude's responses render as rich content:

• Text explanations
• Code blocks with syntax highlighting
• File operations (create, edit, delete)
• Tool use results (terminal commands, file reads, search results)

Messages are laid out by who wrote them. Your own messages sit on the right. Everyone else's, another account member, an agent, or someone writing in from a connected Slack channel, sit on the left with their name and avatar, so a thread with more than one participant reads without guesswork.

Attach an image to a message with the + button next to the composer. See Task Attachments for the sources available on each platform.

The agent activity indicator shows when Claude is actively working. Wait for it to finish before evaluating the result. Claude often makes multiple file changes in sequence.

Tool work collapses into activity lines: one line per call, and a summary line such as ran 3 commands, changed 2 files for a run of them. Tap a line to read the detail behind it. On web it opens under the line; on iPhone, iPad, and Android it opens in a sheet titled with the line you tapped, so the conversation stays where it was.

Who answered and what it cost

A finished turn is signed under the answer with the avatar and first name of the agent that ran it. The turn's own details sit behind that byline: the agent's full name, the coding agent and model behind it, the reasoning effort, the subscription seat billed when a seat rather than an API key paid for it, the tokens used, the API cost, and the time the turn was sent. A fact the vendor does not report is left out rather than shown as zero.

• On iPhone, iPad, and Android, tap the agent's name or avatar under the answer. A turn that names no agent prints no byline and shows its timestamp there instead, and that opens the same details.
• On web, the byline is not a trigger: hover the timestamp under the answer.

Phone and tablet transcripts print no timestamp line under each answer. To see when messages were sent, drag the transcript to the left: every row slides over and shows its time in the gutter that opens on the right.

Sub-Tasks

An agent can hand part of a job to a sub-task: a second run it briefs and then waits on. The brief is machine-to-machine traffic rather than a message to you, so the transcript shows it as one collapsed line in the same muted style as tool activity, labeled with the kind of sub-task and what it was asked to do (for example, → Explore sub-task: Compare the seeded users). Tap the line to read the full brief, and tap again to collapse it.

Dictating a Message

Tap the microphone beside the composer to dictate instead of typing. Your words appear in the composer as you speak, and tapping the button again stops the recording and leaves the text there to edit before you send it. In a browser, Ctrl+D toggles dictation from the keyboard.

Dictation keeps listening through pauses, so stopping to think does not end the recording. It runs until you stop it, or until a five-minute limit it warns you about 30 seconds ahead. The iPhone and iPad composer keeps the microphone available beside a draft, so dictating there appends to what you typed rather than replacing it.

On iPhone and iPad the composer shows a live waveform, the elapsed time, and a stop button on one row while you dictate. Other platforms show a compact recording indicator beside the microphone. Dictation is available on iOS, Android, and browsers with speech recognition, which excludes Firefox, and is not available in the desktop app. The first use asks for microphone permission.

Links to Issues and Pull Requests

A GitHub issue or pull request link in an agent's message renders as a card under the paragraph instead of a bare URL. The card carries the title, an owner/repo · #number line, and the state: Open or Closed for an issue, and Open, Draft, Merged, or Closed for a pull request. View issue and View PR open it, in Wallfacer when the task attached it and on GitHub otherwise.

The title and the state come from the copy Wallfacer already holds as an attachment on the task. A link to something the task never attached still renders as a card with its repo and number, without a title or a state.

When a Tool or File Operation Fails

A failed operation does not turn its row red or print the error into the conversation. The row keeps its ordinary icon and label, and a small red exclamation sits after the label. Tap the exclamation to read the operation's output: in a browser it opens a card under the row, and on a phone or tablet it opens an Error output sheet, so a long error does not push the conversation off the screen.

The collapsed activity summary counts the failures, reading "used 4 tools" with a trailing "1 error" in the same muted text as the rest of the line. Expand it to find the row the exclamation is on.

Copying a Message, or a Link to One

Every agent answer carries two actions in its footer, beside the agent's name:

• Copy Message puts the answer's text on the clipboard.
• Copy Message Link copies a link to that one message. Opening the link goes to the task and scrolls straight to the message, loading older history until it finds it. If the message is no longer in the task, the transcript says so at the top rather than landing you somewhere arbitrary.

In a browser your own messages carry the same pair beside their timestamp, shown when you hover over the message or reach it with the keyboard. Other members' messages show their timestamp only. A message still queued to send has no link yet, because it has no id until the server accepts it.

Large images and payloads

A transcript loads a trimmed copy of each message so a screenshot-heavy task opens quickly. Large images and oversize tool inputs and outputs are not sent with the message; the transcript shows them in place as a labeled placeholder with the size that was left out, such as [82 KB elided], and a sized grey tile for an image or screenshot. Everything else, including the text of the message and the structure of the tool call, arrives as usual, and the transcript keeps filling in live while you read it.

Where the Chat Opens

Reopening a session puts you where you left off, not at the top of the history. If you have unread turns, the chat opens at the New divider, the line that marks the first message you haven't seen. If you're caught up, it opens at the latest turn.

Scrolling up into the history stops the chat from following new messages, so you can read without being pulled back down. Scroll to the bottom again to resume following.

Message Queue

Messages you send while Claude is responding are queued. They're delivered automatically when Claude finishes the current turn.

This also applies during VM boot. Type your follow-up while the VM is still starting. It will be delivered as soon as the session is active.

If a turn is interrupted before it finishes, either because you stopped it or the session was interrupted, your queued messages are not dropped. They stay queued and deliver when you resume the session.

A queued message reads like any other message you have sent, with a Queued chip marking it as not yet delivered. You can remove one before it goes out: on the web, hover the message and click the X that appears; on your phone, long-press it and choose Delete. Once a message has been delivered to the agent it can no longer be deleted, and the control is gone.

When a Send Fails

A dropped connection doesn't cost you the message. If sending a message, changing a task, or attaching a file fails because the network blipped, the app retries it twice on its own before telling you anything.

If it still fails, an alert appears with Cancel and Retry, and it names what actually went wrong: your device is offline, your device is online and Wallfacer could not be reached, or the request timed out and may still have gone through. The alert carries a short reference that identifies the failure in our records, worth quoting if you write to us about it.

Retry repeats the same action, so you don't retype the message or reselect the attachment, and attachments that already uploaded aren't uploaded again. Cancel keeps your work: the message you typed and the images you attached go back into the composer instead of being discarded. The same holds when the app refuses a send outright, for example while an agent's computer is still starting.

Retrying is safe. Each write carries a key the API uses to recognize a repeat, so a message that did get through the first time isn't sent twice. Failures the server authored, such as a rejected request or a permission error, are not retried: they show the server's own message with a single OK.

That key stops being usable after ten minutes. A retry the app scheduled for itself, such as a send that failed while you were offline and was still waiting when you left the app, only goes out if it runs inside that window. Later than that, the app can no longer tell a send that never left from one whose reply was lost, so it refuses the attempt instead of risking a second copy of your message: you get "We could not confirm this went through, so it was not sent again. Check the conversation before sending it again.", and your text goes back in the message box. Pressing Retry yourself, or sending from the message box again, counts as a new send and is never refused this way.

While your device is offline, the app pauses work instead of retrying it. See Notifications for what happens offline and on reconnect.

Idling and Resuming

Sessions default to a 5-minute idle timeout, configurable between 60 and 900 seconds when you create the task or session. When the timeout elapses, Wallfacer marks the session idle and destroys the VM to release resources.

Send a new message to reactivate an idle session. Wallfacer boots a fresh VM from the environment snapshot, restores the transcript, and delivers the queued message when the session is active again. On iOS and Android, you can send that message straight from the session's idle push notification without opening the app. See Notifications.

Closing a Session

Close a session to release VM resources when an attempt is done. Conversation history remains available in the task, and sending a new message can reactivate the session when the platform can safely do so.

Snapshots make re-opening faster than a fresh setup, but failed environments, missing capacity, or terminal session failures can still block a resume.