Tasks
Use task detail and status to move one piece of project work from request to outcome.
Before you begin
Open the intended project and write a bounded request. Include the outcome, constraints, relevant repository area, and a check that can prove completion.
Request anatomy
Use four short parts rather than a long stream of context:
After submission, task detail should preserve the request and show Details, Graph, Review, and Terminal tabs when their data or routes are available. The activity list is the chronological source for session progress, plan decisions, check results, and repository actions.
Before submitting a repository-changing task, open New task in the Labor0 app. Then inspect every repository the task will use in the Repositories guide: open the project's visible Repositories item and confirm each repository's Read-only or Read-write access and Auto PR status. Repository access policy can prevent publication even when the prompt requests a commit or push. Publication is decided per repository; when no existing pull request is applicable, that repository's Auto PR setting determines whether Labor0 creates a pull request automatically or initially publishes only a branch.
Changing these project-wide defaults requires Workspace Operator or above. Viewers can inspect the settings but cannot save changes or submit the project task; ask a project or workspace Operator or Admin to make the update. A Workspace Operator or above must select Submit task after the settings are ready.
For local execution, install the complete Labor0 CLI bundle and follow Set up and run before submitting a browser task. Auto prefers an eligible active local runner but may use hosted fallback. An active online CLI-managed runner does not currently enable Local only because Labor0 cannot confirm readiness for the selected coding-agent runtime. Local only never falls back to hosted execution. Confirm final Local runner attribution before continuing; if hosted fallback is unacceptable, do not submit the browser task with Auto, because hosted work may begin before final attribution is available; stop before retrying and use Manage and troubleshoot.
These are project-wide defaults for subsequently created coding tasks and sessions. Before changing them for a one-off repository-analysis task, record the prior values and coordinate with the project owner or affected teammates. If you change a repository binding to Read-only, that is also a project-wide change rather than a setting for only the new task; check for in-flight work, coordinate with affected teammates, and restore the prior access after the analysis, or use a separate project or repository binding. When an existing binding is Read-write, use the repository guide's Detach, Attach from catalog, and Read-only controls to replace it, then reverse those controls to restore the recorded access. If Require plan approval for coding sessions is not enabled under Project settings > Plan mode, enable it, select Save plan-mode defaults, and confirm the setting is enabled. If Approve per-task coding plans automatically by default is enabled, disable it, select Save coding-plan auto-approval, and confirm the setting shows manual approval before selecting Require plan approval before implementation. Otherwise the plan may be approved automatically and implementation or publication can begin before you can choose Request changes or Terminate task. After the task, first restore the recorded automatic-approval value and select Save coding-plan auto-approval while plan approval remains enabled; then restore the recorded plan-approval value and select Save plan-mode defaults, when safe and coordinated.
Repository publication for project task-graph work: When Labor0 executes work that changes repository files in a Read-write repository, wording such as “do not commit,” “do not push,” or “do not create a pull request” may constrain the requested content, but it cannot disable that repository's configured publication outcome. Required commits and pushes still occur when the repository access policy permits publication; an existing pull request is updated when applicable, automatic pull requests create a non-draft pull request, and disabled automatic pull requests initially publish to a remote branch created for the task. A task using multiple repositories can therefore have a different publication outcome for each repository. The result is that read-only work does not publish changes. Not every task creates a pull request. For non-repository questions, use a clearly read-only conversation or analysis surface such as Workspace Chat · Beta; it cannot inspect attached repositories. For repository analysis, enable Require plan approval for coding sessions, save the plan-mode defaults, disable automatic coding-plan approval, save that setting, and select Require plan approval before implementation in Advanced settings before selecting Submit task for a project-scoped task. Plan review is a review workflow, not a hard publication-prevention control for a Read-write repository. A Read-only binding alone is not a hard nonpublication boundary for a local runner that can inherit alternate Git or SSH credentials; guaranteed nonpublication requires an isolated execution environment without alternate write credentials, or another enforced nonpublishing surface. In the isolated hosted workflow, select Hosted only in Advanced settings and verify that selection before submitting. Then review the Plan and choose Request changes or Terminate task before implementation instead of relying on a publication prohibition in the prompt.
If unwanted work has already been published, see Troubleshooting for the visible Remove action and repository-policy recovery for changes that have already merged.
Procedure
- Create or open the task from the project work area.
- In Details, compare the saved goal and constraints with the current task status.
- In Graph, inspect the selected task's parents and children before treating a waiting state as a failure.
- Read Task activity from newest to oldest. Loading more activity appends older history. Use the offered Plan review, Request, Session, Terminal, or retry action rather than guessing from elapsed time.
- Open Review for the available checks or pull-request evidence.
- Confirm the final checks and pull-request state separately from the task's terminal state.
Expected result
The task title, project name, and status remain visible while you move between its tabs. A user-input pause produces Attention required and a Request action. A resolved plan decision produces Plan review outcome with Approved or the recorded non-approval result. Completed work keeps its activity history so the reviewer can trace the request to the final evidence.
Clarify a pending question
Limited availability: Side chat is currently enabled only for selected workspaces. Even when a pending question meets the conditions below, Open side chat appears only where the capability is available.
For some agent questions, Open side chat lets you ask for clarification without answering the pending question. For example, enter Which existing behavior would this choice preserve? in Side chat. Labor0 replies in the drawer or sheet while the original question and Submit answer remain available.
Side chat is read-only inspection: it cannot change repositories, publish work, resume the task, or choose an answer for you. Messages are kept with the owning task and follow that task's retention and deletion boundaries. A shared question shows participant messages with display names, but does not expose email addresses or account identifiers.
The control appears only for an eligible pending agent question and only while you still have permission to participate. For a private task, only its creator can see the history. For an individually addressed question, only the addressed person can use it. For a group question, current eligible group members share one history; a newly eligible member can see it, while a removed member immediately loses access.
While Labor0 is generating a reply, the message box is disabled. A failed reply leaves the question pending and offers an explicit retry; it never retries or submits the answer automatically. If someone submits the final answer, cancels the question, or finishes the task first, any active reply stops and the retained history becomes read-only. The visible confirmation for a successful clarification is the assistant reply in Side chat; the separate confirmation for answering is the normal recorded answer after you select Submit answer.
If Open side chat is absent, continue with the normal answer form. If a reply fails, read its safe status and retry once. If history becomes read-only, refresh the task and inspect the recorded question outcome before taking another action.
Permission guidance
Task visibility, plan approval, retry, and repository actions can differ by role. Keep the task in its project scope and ask a project owner when a control is unavailable.
If a task is failed
Symptom: status is Failed or Blocked. Likely cause: a prerequisite, check, dependency, or requested input did not complete. Safe recovery: read the newest activity and app diagnosis, correct the named prerequisite, and use the task's retry or follow-up action once. A blocked dependency should be repaired at the dependency, not by repeatedly retrying the child.