Coding workbench

Application menu

macOS uses the system menu bar. The frameless Windows and Linux windows show an application-menu button at the left of the title bar (also reachable with Alt+F or F10).

The menu contains only unambiguous, genuinely useful items: Application (About, Settings, Services, Hide, Quit; About opens the in-app About page), Edit (undo, redo, cut, copy, paste, select all), File (new task tab, new project space tab, close workspace tab), Work (Tasks, Project spaces, Plugins, Scheduled, Applications), View (Search tasks, toggle sidebar/side panel/terminal, toggle full screen, font size), Window (Minimize, Close window, Show main window), and Help (GitHub project, report an issue, developer tools; report an issue opens the in-app feedback form).

Menu items follow the current workbench state: when an action is not available on the current surface — for example there is no closable tab, or the active surface is not a task workspace — the item is hidden instead of remaining as a clickable entry that does nothing. Menu actions reuse the controls that already exist in the interface; they never introduce a second navigation path.

The Developer tools submenu also offers a Process Explorer. It opens a separate window that shows a collapsible tree grouped by the object that owns each process: the application, its windows (including embedded browser views), local runtimes (core runtime, executor, workbench runtimes, plugin development, and their children), and Chromium helpers. Each row shows the process name, process ID, CPU, memory, and uptime; selecting a row shows its launch details in the footer. Column widths can be adjusted by dragging a header edge and reset by double-clicking it. A filter matches names, PIDs, and launch details. The selected row detail is shown in full in the footer, can be scrolled when long, and can be copied with a small icon; there is no diagnostics export. The window follows the current WeWork language and theme, and can be pinned on top. The explorer is read-only and never terminates a process; a full WeWork restart remains the reliable recovery path.

Process attribution and collection have the following limits:

• Tabs in the main window share a renderer process, so its memory cannot be split by tab. Independent workbench runtimes can be attributed to their tabs.
• Executor children are grouped under the executor, without mapping them to individual tasks. Orphaned processes from a previous launch that have left the current process tree are outside the collection scope.
• The explorer does not start periodic process collection until its window opens, although the application still loads the related modules and initializes the collection service. The open window refreshes every two seconds, including while minimized. Closing it stops periodic refreshes; an outstanding collection may still finish.

Use top-level tabs

The Wework desktop app uses top-level tabs for tasks, project spaces, agents, and other product pages. Sidebar links navigate within the active tab. A new tab is created only when you select the top-bar + or another explicit new-tab action from a tab menu.

When experimental features are enabled, the first main window shows three default tabs: Task, Workspaces, and Agent. When experimental features are off, the Workspaces tab is hidden. Every tab is an independent work instance. Two Task tabs retain separate conversations and unsent drafts, two Workspace tabs retain separate projects and routes, and two Agent tabs retain separate page state. Switching tabs does not synchronize content from another tab.

Task and Workspace tabs retain their mounted interface while they are in the background instead of recreating it whenever the user returns. Unsent drafts, the selected project, board routes, and panel state therefore restore immediately, and background tabs do not restart the workbench runtime. The first Task workbench centrally prewarms the Codex app catalog needed by composers; mounting a composer or switching tabs does not request the catalog again. A Workspace board loads task-composer model and skill catalogs on demand only when the user creates a runtime task from an issue, avoiding the complete Task-workbench startup cost during ordinary board browsing.

When many tabs are open, the tab list scrolls horizontally while the + and the rightmost feedback button remain visible. A tab can also be moved to a separate window from its context menu. After the move succeeds, the source window removes the tab and the destination window contains only the moved tab and its state; it does not create the three default tabs again. If destination-window creation fails, the source tab remains unchanged.

In a separate window, right-click a tab and choose Move to main window to return it with its current page and unsent draft. Fixed tabs remain fixed and restore in the main window after restarting. Moving the last tab closes the separate window; a window with other tabs stays open. If the main window cannot accept the tab, it remains in the separate window.

The Task page and auxiliary product pages such as Plugins and Cloud Work share the same full-bleed desktop content container below the title bar. Switching pages within a tab therefore keeps the left sidebar's position and chrome stable instead of shifting with the page type. Pages may still render their own internal chrome inside this container.

Configure board automations

Under Automation in a project space, choose a scheduled trigger and select daily, weekdays, weekly, or Hourly. Hourly schedules support minute 0–59 and use the configured timezone.

Scheduled automations have a Run button on both their list card and detail view, including when their schedule is paused. Save configuration changes before running. The button is disabled while a run is starting to prevent duplicate submissions and becomes available again after a failed start. View results in run history.

Manage issues and tasks in workspaces

The top-level Workspace tab is where users browse boards, issues, and their linked tasks. It remains independent from Task tabs, preserving its selected board, route, and interface state.

The Task-page sidebar names this destination Board. After it opens, the system-managed personal board is still titled My tasks, distinguishing the top-level product area from the specific board being viewed. My tasks exposes only board-oriented task tracking, including search, creation, filters, and task details. It does not show the table, files, automation, management, or project-action menus; those advanced capabilities remain available only in ordinary project spaces.

Selecting the fixed top-level Workspace tab from another page opens My tasks; selecting it again while it is active preserves the current board. Even when both local and cloud storage contain a system-generated default-work-items space, the sidebar presents a single logical My tasks entry instead of two identically named destinations.

Selecting New Issue in a workspace opens a lightweight composer instead of a task form. Choose the destination board and describe the outcome in natural language; the first non-empty line becomes the title and the remaining text becomes the description. The issue is created directly in the selected status column and opens immediately for follow-up details such as participants and execution steps. The board header and every status column expose the same creation flow.

Without any setup, new tasks select My tasks by default. Sending the first message creates a work item, links the runtime task, and keeps its execution status synchronized. Existing runtime tasks are also linked into My tasks, so this board is another view of the Task-page inventory rather than an independent task list.

On local boards, when a linked task finishes and moves to In review, its card shows an unread dot, a blue border, and a light blue background, with a muted blue surface in dark mode. Opening the item details marks it as read; returning to the board preserves its normal appearance. A subsequent run with a new result makes the card unread again.

Every runtime task has at least one system-managed My tasks issue. A user may additionally link the task to one issue in a local or cloud project space. Task context prefers the user-selected issue and falls back to the system issue when no user link exists. The system issue remains linked and receives runtime status, task-title, and archive-state updates even after the extra project-space link is removed, so unlinking another board never removes the task from My tasks. Issues may also exist without a runtime task, which is why an ordinary project-space board is not itself a task inventory.

A newly created system My tasks issue contains only a projection of the runtime task title and description, so Wework does not inject it as independent project context into the first model request. If a user later changes the title or description, or adds priority, hierarchy, participants, tags, workflow, a due date, attachments, deliveries, or comments, the Executor marks the issue as containing additional context. Wework reads the current issue again before a later turn and injects that new context. Status changes produced only by the runtime lifecycle do not enable injection.

Lanes follow actual execution state: a task that is explicitly queued but has not started appears in To start, and an active task appears in In progress. Successful, stopped, cancelled, and failed tasks all enter To confirm. A successful run means execution has ended; it does not automatically accept the work as completed. After confirming the result, the user can manually move the card to Completed. Confirmation cards show the linked task and the first three lines of the final AI response so users can decide whether more work is needed. Archived runtime tasks are excluded from the completed lane. The completed lane also provides batch archive, with an additional confirmation when a workspace still contains uncommitted changes. Batch archive processes all linked runtime conversations in one operation, removes successfully archived cards from the board, and keeps failed cards in the confirmation dialog for retry.

Hover anywhere on a board card to open a task-progress panel at a stable position in the viewport's upper-right corner; moving across cards does not make the panel jump with each anchor. Its header shows the current issue title. When the runtime exposes one, the preview shows the current conversation goal. It directly reuses the task conversation component and always starts at the latest message instead of restoring the Task page's saved scroll position. While the current turn is active but has not produced new response text, the preview does not present the previous turn's final response as the latest progress. When a runtime task is associated with a board item, both local and cloud task bindings must persist that conversation's model selection. The preview restores the model from the binding instead of falling back to the global default for new conversations. Message loading, live updates, continuation, and attachments behave exactly as they do on the task page, with the composer collapsed by default. In the normal preview state, the panel remains visible while the pointer stays over either the card or the panel; it closes after you leave both areas, scroll the surrounding board, or press Esc. Clicking the card's task-progress area, the pin action in the panel header, or the composer pins the same panel in place instead of opening a separate side conversation. While pinned, hovering other cards does not replace its content; clicking another card's task-progress area switches the pinned panel in the same position. Use the top-right close button or press Esc to leave the pinned state and restore normal hover previews.

The work-item control above the composer shows the current project or linked issue and provides actions to view its details or board. Opening the linked board focuses the work item while preserving the original Task tab. If a board tab for the same project is already open, Wework reuses it instead of loading a duplicate board; otherwise, it creates a board tab.

When changing the composer's project-space association, filter by owning space on the left. Each project on the right shows its name, key, and owning space to distinguish duplicate names. Search combines project names, space names, and project keys. Projects default to ascending name order, with descending order also available. In the search field, use the arrow keys to select, Enter to confirm, and Esc to close. Do not add to another project space removes the extra association.

Local projects do not each create a separate board. Their tasks share My tasks and carry a project field, so project views can filter the same work-item data.

Create issues from external systems

Maintainers of a cloud workspace can create an event subscription for a source (GitHub, GitLab) from inside the automation rule configuration. Configure the generated Webhook URL in GitHub, GitLab, Sentry, Grafana, an alerting platform, or any system that supports HTTP callbacks. Each accepted external event is deterministically converted into an unassigned issue in the workspace inbox. Existing task.created automation rules continue to run after the issue is created.

Note: Event subscriptions are created and managed together with the automation rule that consumes them. Pick a source (GitHub, GitLab), then add the resource URL; the Webhook URL for the created subscription is shown on the same page, ready to copy into the external system.

The hook address contains its own credential. Treat it as a secret and do not store it in a public repository or log. Select Rotate address if it is exposed; the old address becomes invalid immediately. Disable the hook when intake must be paused. This capability currently supports cloud workspaces whose tasks are managed by Wework.

Built-in adapters recognize GitHub Issue opened and reopened events, GitLab Issue open and reopen events, and unresolved Sentry and Grafana alerts. Closed, resolved, or titleless events do not create issues, but their receipt is recorded. The same external event ID, delivery ID, or request body is processed only once.

Other systems do not need to implement a Wework-specific protocol. They can send JSON, form data, or plain text. Generic JSON must provide at least one of title, subject, summary, name, or message:

curl -X POST '<Hook address>' \
  -H 'Content-Type: application/json' \
  -H 'Idempotency-Key: incident-2026-08-16-001' \
  -d '{
    "title": "Production payment failures",
    "description": "The error rate crossed its threshold. Investigate and restore service.",
    "url": "https://monitor.example.com/incidents/001"
  }'

For plain-text requests, the first line becomes the title and the complete body becomes the description. Request bodies are limited to 1 MiB. The service returns HTTP 202 with a status of created, duplicate, ignored, or failed; a created response also includes the new issue's loop_item_id.

Move between issues and runtime tasks

The issue details' Execution history section lists linked Wework runtime tasks. Selecting a record opens the issue context and task conversation side by side in the unified workspace; select Open full task only when the complete execution interface is needed. Board and Task tabs retain their own routes and interface state.

Board cards continue to represent issues; Wework does not create separate PR or MR cards. When a linked task has a PR or MR, its task icon in the execution history is replaced by the change-request status icon. The project sidebar on the Task page reuses the same state and interaction. Running tasks are always shown. A stopped task remains visible only while its PR or MR is open; it is hidden after the request is merged or closed, or when no request was created.

Status lookup runs through the Executor on the device that owns the task. A local task uses the locally authenticated gh or glab CLI and does not require separate REST task authentication for the board. Wework batches branch lookups by repository and stores results in a local cache instead of querying once per task. Visible pages refresh periodically and check again when the app regains focus.

When a description, comment, or AI reply is written, GitHub PR and GitLab MR links in that content are recorded in the issue's generic metadata.badges. Board cards show a compact status icon and request number without requiring a linked runtime task; hovering reveals status details and selecting the badge opens the link. Metadata stores the association. An independent client PR module continuously refreshes status through the local gh or glab CLI and projects it into generic badge display data. Board and detail components neither recognize PR URLs nor query status. The business module subscribes only for visible badges, shares existing queries and cached results for identical links, and limits linked lookups to four concurrent requests. Automatic queries allow the public GitHub/GitLab HTTPS origins, hosts configured in GitHub CLI, GitLab CLI's global host, and origins explicitly configured through GH_HOST / GITLAB_HOST. HTTP requires an explicitly configured HTTP origin. Unconfigured origins remain links without receiving automatic queries. Opening a board does not fetch each issue's comments, and historical content is not scanned or migrated. Disabling PR/MR status lookup keeps the link badges visible.

When checks fail, a merge conflict exists, or Merge Queue enters an abnormal state, the status menu provides Continue with AI repair. This action continues the original runtime-task conversation with the failure context instead of creating another task. Closed PRs and MRs do not expose the repair action.

Use the project sidebar

Select a project name to expand or collapse its runtime tasks. Collapsed projects use a closed-folder icon; expanding a project changes the icon to an open folder so its state is easy to recognize.

New tasks appear immediately at the top of their project's task list. Tasks with a saved drag order continue to follow that manual order; after a new task receives its persisted order, it remains stable within the same project ordering.

Handle AI questions

The top-level Needs your input tab collects structured questions from task conversations, projects, and your stand-in. Its left list groups questions under Tasks, Projects, and Stand-in, newest first within each group. Empty groups are hidden. Each question appears once; project questions initiated by your stand-in belong to Stand-in.

When in-app notifications are enabled for the relevant source, new questions show a reminder while the app is in the foreground. Questions already being viewed in Needs your input do not trigger another reminder. Closing the reminder only hides the popup; the question stays pending. Select a question to read its original conversation or Issue context, or use Open in original view to return to its source.

To leave a question unhandled, hover over its left-list entry and click the cross, Dismiss item. The action is also reachable by keyboard and remains visible in narrow windows. It moves the question to Handled without sending an answer or approving an operation. Later questions in the same conversation still appear normally.

Select Collapse or press Esc on a business question card to keep your answers and return to the ordinary message composer. Select Expand reply to resume answering. Collapsing never cancels the task or submits an answer. The old card closes after a new message is successfully delivered in the original conversation; failed or queued messages leave the question available to reopen.

When you are unsure how to answer a business question, select Talk it through on its question card or in the question details in Needs your input. Wework opens the right sidebar and prepares an editable question in its composer. Edit it and select Send to begin an independent discussion; opening alone never sends a message. The original question stays open. Closing and reopening keeps the discussion and unsent message.

After discussing, select the text you want to use and choose Fill answer from the selection toolbar. For multiple questions, choose the target at the top of the sidebar first. Review and edit the selected text in the original answer before submitting. Filling a draft never sends an answer or approves an operation. Questions that were handled, cancelled, expired, or whose current state cannot be verified cannot receive a draft. Permission approvals and connector authorization retain their native confirmation flows.

Answering or cancelling a question in its original task or project view automatically synchronizes and archives it. Handled history retains the source groups. Both handled and dismissed records are stored locally for the current account and survive restarts. Already loaded questions remain available offline and synchronize when the device reconnects. Discovery of questions on a healthy local executor does not depend on its cloud device status.

Use IM notifications

IM notifications are generally available and do not require Experimental features. Use the message-bubble entry in the sidebar account area to configure away-from-computer reminders. After opening a runtime task, select Continue in private chat in the title bar to bind that task to an available IM private chat.

The away-reminder panel shows the current delivery conversation. When cloud connectivity is available, Change conversation and the primary enable or disable action remain fully visible in the same action row, so either setting can be adjusted directly.

After binding succeeds, Wework's switch confirmation uses the current task title instead of an internal runtime-xxx task identifier. Later task replies continue to be delivered to the selected private chat.

Split tasks by dragging

Drag a task from the sidebar to the top, bottom, left, or right target in the workbench to create a split in that direction. Dropping on the center target replaces the task in the current area. Once the pointer enters the workbench, sidebar sorting and automatic scrolling stop so they cannot take over the split operation. Move the pointer back into the sidebar to resume task reordering.

A split is saved as a conversation group. Tasks in the same group show the same Split N badge in the sidebar. Selecting any member restores the complete split group and focuses that task. Selecting a task outside the group switches to a single-task view without replacing a member of the saved split; selecting any member later returns to the group. Multiple split groups can be retained, but a task belongs to only one group at a time. A group dissolves automatically when closing panes leaves only one task.

When a split pane has limited height, an idle composer automatically collapses to a single text line and a smaller send button, hiding attachment, quick-phrase, model, and other feature controls. Selecting or focusing the composer animates it back to the complete input surface; selecting outside collapses it again. The composer remains expanded when attachments, code comments, mode settings, or other pending context must stay visible.

Start a new task

The new-task page uses compact suggestion buttons to help choose a task direction. Selecting a direction reveals more specific prompts. Selecting a prompt writes it into the composer, where it can still be edited before sending.

Project selection, message input, quick phrases, and model selection share one composer surface. The composer shows a blue border while focused, and the simplified launcher preserves project, attachment, quick-phrase, and model controls.

After startup, the active task composer receives focus when it becomes available. Returning to the window restores composer focus if no other control holds it. Configured Command / Control shortcuts remain available while the composer is focused; ordinary text, IME composition, and Option-only text input stay with the editor.

Use the Popout Window composer

When no task is running, the Wework Popout Window uses a compact composer with a fixed height. After the message exceeds three lines, the text scrolls inside the editor while attachment, model, and send controls remain visible.

Files and terminals

The right workspace displays project files, previews, and change reviews. Multi-root projects show a folder selector in the Files tab. Switching folders changes only the file-tree and preview root; it does not change the execution directory used by the task, terminal, or conversation.

Selecting a writable text file opens it directly in the editor without a separate Edit action. Changes autosave after about three seconds, so the editor does not show a manual Save button. Markdown files can switch between the editor and rendered preview, while read-only text and binary files remain in preview mode.

Local file and directory links in an AI response open in the Files tab. File links can jump to referenced lines, while directory links make that directory the file-tree root. In the macOS desktop app, the Files tab's Open and Open location actions support both files and directories.

Codex file citations appear as clickable filenames for presentations, spreadsheets, PDFs, documents, and code. Source citations appear under Sources, while deliverables appear under Outputs. Code line references open at the requested lines. Page numbers, slide numbers, worksheet ranges, and object labels appear beside the filename; clicking opens the file but does not yet navigate to an Office artifact's internal location. Legacy 【F:path†Lstart-Lend】 references also support code line navigation.

Citation paths preserve literal filenames, including Unicode, spaces, percent signs, and other special characters. Code examples, user messages, and escaped citation syntax remain literal. Follow-up suggestions display their title; their copy action copies the complete prompt for a subsequent message.

Press Command+J to open or close the bottom workspace panel. Opening the panel does not create a new terminal automatically. Existing terminals are preserved per task and restored when you return to that task.

Select + in the bottom tab bar to choose Terminal, IDE, or Desktop, depending on the active device's capabilities. Terminal starts in the active project or the task's Git worktree. IDE opens in the system default browser. When available, Desktop opens in Wework's built-in browser.

When diagnosing a terminal that does not repaint after a task switch, frontend logs record the terminal type, task and session identifiers, activation phase, xterm row and column count, container dimensions, and hidden state. They never record terminal output, commands, or workspace paths.

To diagnose [Terminal connection failed], correlate Local terminal start, Local terminal connection, Electron local terminal attach, and Local terminal close logs by session identifier. The logs include the host process, child process, task, workspace path, connection stage, and close reason so output-listener, exit-listener, native-attach, missing-session, and intentional-close cases can be distinguished. They never include terminal input, output, executed commands, or environment-variable contents.

Expand the right workspace

With the right workspace open, select Expand panel in its title bar to let files, previews, or change reviews fill the main workspace. The task composer is hidden while a non-chat workspace is expanded; an expanded temporary chat keeps only its own composer. The expanded state is saved per conversation.

You can still collapse the left sidebar while the workspace is expanded, leaving only the right workspace visible. Select Restore panel in the upper-right corner, or Latest turn at the bottom when a conversation is available, to return to the side-by-side conversation and workspace layout. Closing the right workspace or its last tab also exits the expanded state.

View execution progress

While a task is running, the conversation shows the tools in use and the current progress. Completed tool calls collapse into summaries that can be expanded to inspect commands or changed files.

After a parent agent starts a subagent, the subagent activity remains anchored at its original invocation position. Later status, progress, and result updates appear at that position even if the parent continues producing other output; the activity does not move to the end of the conversation or render a second time.

Click a subagent activity to view its execution in the right workspace. The panel shows model-provided reasoning summaries, progress messages, tool calls, and results in order. Content updates live while the subagent runs, and saved process content remains available after completion or reloading the task.

Navigate long conversations

When a conversation is taller than the current viewport, turn markers appear along the left side of the message area. The navigation stays centered in the conversation viewport instead of scrolling with message content. Select a marker to jump to that turn, or hover over it to preview the user request and assistant response summary.

While an assistant response is still growing, navigation keeps the current turn active until the message area finishes its next layout measurement. This prevents bottom-follow scrolling from briefly clearing the marker or switching it to another turn.

Switch conversations and restore position

When switching conversations, the desktop workbench saves runtime state, recent messages, right-workspace tabs, and panel state, so returning restores the workspace as it was left. The Files tab restores the selected file and its actual directory, including absolute paths opened from assistant messages outside the workspace root. The Review tab restores the selected review scope and loaded diff. Ordinary conversations do not retain a hidden full-page DOM, which bounds WebView memory growth from long conversations.

Conversation panes with a running Terminal or Wework built-in browser remain mounted. Terminal processes, tabs, and output buffers stay live, while built-in browser pages, addresses, and tab state are preserved. After those resources close, the pane can be released while its restorable panel state remains. Hidden conversations do not handle shortcuts or browser-open events intended for the active conversation.

A conversation opens at its latest message the first time. Conversations that were at the bottom remain at the bottom, while conversations viewed in the middle restore their distance from the bottom. Long conversations mount only messages near the viewport and reuse measured message heights to limit WebView memory growth while scrolling.

Message, scroll-position, and measured-height caches are bounded. Archiving a task evicts its cached state immediately. If an older entry has already been evicted, Wework reloads the complete transcript from the local runtime when it is opened again.

After restoring a conversation, you can answer an existing MCP form or another runtime request that expects a direct response even while the model catalog is loading or the configured model is unavailable. Sending a new chat message still requires an available model.

Use selected response text

Select text in an assistant response to add it to the current conversation composer or ask a follow-up question in the sidebar. These actions remain available while the response is streaming; later content updates do not dismiss an action menu that is already open.

Process text shown above tool calls while a task is running is also selectable response content. Selecting it opens the same action menu and can add the text directly to the current task composer.

Review and undo changes

Supported Git tasks show a per-turn change card with file and line counts. Select Review to inspect the complete diff in the right workspace. Normal review mode keeps every file diff rendered. Selecting a file in the tree, or opening a specific changed file from an assistant message, scrolls the content to that file instead of hiding the other files. The original execution device must be online.

The review toolbar supports unified and split layouts. The file tree can be shown or hidden; showing it again preserves its filter, selected file, and scroll position. Selecting a file name in a diff heading opens the right-side Files tab at that file's first changed line. Selecting an additions-side line number that maps to the current file opens the corresponding source line. Deletion-side line numbers do not map to the current file and therefore do not navigate.

For unstaged changes, use Stage or Revert on an individual file or hunk. For staged changes, use Unstage on an individual file or hunk. These actions affect only the selected file or hunk and leave the other changes from the turn untouched.

Select a code range in the diff to add a comment. The comment returns to the current conversation composer as code context, supporting a review, feedback, AI revision, and re-review loop.

Select Undo to reverse only that turn. Wework checks the reverse patch first and will not overwrite conflicting later changes.

Before pushing, review every changed file, run relevant tests, check for temporary or sensitive files, and confirm the commit and target branch. Preserve uncommitted changes before archiving a worktree task.