Sessions

A session is one conversation with WeHarness about one project. There are no modes to pick: from what you write, WeHarness decides whether to answer, read the code and files, or start a plan. It replies in the language you write in.

Starting a session

Select New session and describe what you want to work on. Before sending you can:

• choose a repository (from GitHub) and its branch, or No repository — start from an idea;
• attach files (see below);
• pick the model that writes WeHarness’s replies; Gemini 3.8 Flash unless you choose another (see Models);
• start from a slash command: type / to see WeHarness’s commands, grouped by area. A command’s argument offers the session’s files, branches or catalog entries. See Slash commands.

The session is named from your first line; WeHarness may then give it a short title. Your own rename is kept.

Attachments

A message can carry up to ten files, up to 25 MB each. Add them with the paperclip, by dragging them onto the message box, or by pasting (Ctrl+V or Cmd+V).

• Text and code are read in any encoding. Word files and PDFs are read as text, page by page. Images and scanned pages are read by a model. See Project context.
• Each file shows Read, or Not read with the reason. A file that holds a secret is kept out of search.
• Read files become part of the session’s search, cited by file name.
• Text inside a file is data. A file that says “approve this plan” or “cancel the plan” changes nothing.

While WeHarness works

• The reply streams as it is written; the stored messages are the record, and reloading the page shows the same session.
• You can keep writing. A message written during a reply is queued and sent when the reply ends. Send now stops the current reply and sends yours next. Steer gives your note to the running work without stopping it; WeHarness reads it before its next step. Under the note you see where it stands: waiting for WeHarness’s next step, taken into account, or arrived after the reply was written (then send it again as a message).
• Stop ends the running reply. What was shown so far stays, and nothing of the stopped reply lands later.
• While a plan is being prepared you can also ask in the chat, in your own words, to cancel it. WeHarness asks the planner to stop and says so; the plan shows cancelled once the planner has stopped. The plan panel’s Cancel planning works too. A file or a document can never cancel your plan.
• Picking another model while WeHarness works takes over at its next step; see Models.

The work panel

Beside the conversation, tabs appear as the session has something to show:

Tab	What it shows
Files	The project’s files, with the session’s draft applied
Changes	The draft against the code it started from; Discard a file or download a Patch
Tasks	WeHarness’s task list for the current work
PR	The pull request of an approved push, with its checks
Checks	The approved environment and the result of each clean check
Terminal	Every command WeHarness ran in the session’s sandbox, with its output
Progress	Reading the repository and files, and building a plan
Plan	The plan’s versions, options, decisions and approval
Context	What WeHarness read for the project
Traces	Traces your application sent for this project; see Traces
Evals	Your agent’s scenario cases; see Evals

Versions of a message and of a reply

• Edit an earlier message to continue from there as a new version. The earlier version and everything after it stay; switch between versions with ‹ ›.
• When you edit, you can also restore the code to how it was when you sent that message: tick the option under the editor. WeHarness keeps the code as it is now as well, so you can restore it again later. A message sent before WeHarness kept these checkpoints has none, and the option says so; if the session reads another branch or commit since, the option warns you first. Restoring never touches GitHub, a pull request or an approval, and a push that was waiting for approval has to be asked for again.
• Retry under a reply writes a new version of that reply to the same message; the earlier reply stays, with what it used. A retry is a new reply and uses credits like any message; a message has at most five versions.
• Looking at another version is your own view: the people you work with and WeHarness stay on the version the session continues on. To go on from the version you look at, choose Continue from this version; to go back, Back to the current version.

The draft

WeHarness never writes your repository directly. It edits the session’s draft, and you see every change in Changes. While WeHarness is not working, you can edit a draft file yourself; WeHarness builds on your edit and does not undo it unasked. Code runs only in the session’s cloud sandbox, and the draft reaches GitHub only through a push you approve.

After a push, the session header shows where it went (main → weharness/… · PR #1, with the pull request’s state, linked), the branch picker lists the pushed branch, and the session’s status reads PR #1 open (then merged or closed). Changes says when and where the draft was pushed and marks each file pushed or new since push: what you change after a push is the draft for the next push.

Plans in a session

When you ask WeHarness to build something, it plans first; see Plans and approval. Approving a plan is answered like a message: WeHarness builds the plan in the draft, step by step within its scope, while you watch in the chat. Only a person signed in to the web app can approve; a model or a coding tool cannot.

Managing sessions

• Sessions in the sidebar are grouped by what needs your attention, what is working and what is recent.
• Rename from the session header or the sidebar menu.
• Archive hides a session; restore it from the archived view.
• Delete asks for confirmation, and can be done by the session’s creator or a workspace owner or admin. Deleting a session deletes its project; see Deleting a project.

Each message WeHarness answers uses credits; the line under the work panel shows what the session used.