Managing Code Tasks
This guide explains how to create, execute, and manage code-type tasks in Wegent.
Table of Contentsβ
- What is a Code Task
- Creating a Code Task
- Task Execution Flow
- Task Status Management
- Sending Follow-ups While Running
- Advanced Features
- Viewing Codex-generated Visualizations
- Cleaning Stale Runtimes
- Common Issues
What is a Code Taskβ
A code task is a task type in Wegent specifically designed for software development. Unlike regular chat tasks, code tasks connect to Git repositories, allowing AI agents to make code changes directly in the repository.
Core Concept:
Code Task = User Prompt + Code Agent + Git Repository + Branch
Code Tasks vs Chat Tasksβ
| Feature | Code Task | Chat Task |
|---|---|---|
| Git Repository | Required | Optional |
| Code Execution | Runs in Docker container | No code execution |
| Workbench | Shows file changes, commit history | Not displayed |
| Branch Management | Auto-creates feature branches | None |
| Use Cases | Development, refactoring, bug fixes | Q&A, analysis, documentation |
Creating a Code Taskβ
Step 1: Open the Code Entryβ
- Click "Code" in the left navigation bar to enter coding mode at
/chat?agent=code - The system displays the code task list and input area
Step 2: Select a Code Agentβ
Above the input area, click the agent selector:
- Click the agent dropdown - Shows available agents
- Select a code-type agent - Choose an agent configured with a ClaudeCode Shell
β οΈ Only agents configured with a code-type Shell can execute code tasks
Step 3: Select Code Repositoryβ
- Click the repository selector - Shows repositories you have access to
- Select target repository - Choose the repository for code changes
- Select branch - Choose the base branch (AI will create a new branch from this)
Step 4: Configure Task Options (Optional)β
Model Selectionβ
Click the model selector to override the agent's default model:
- Select model: Choose from the dropdown list
- Force override: When enabled, uses your selected model even if the agent has a configured model
When you switch to a different model in an existing Wework conversation, Wework asks for confirmation first. Different models may interpret existing context differently and may vary in tool support, response style, and task continuity. After confirmation, the new model is used for the next message; a response already in progress continues with the previous model. No warning is shown when selecting a model for a new conversation or reselecting the model that is already chosen.
Friendly Titlesβ
You can enable Use friendly titles under Settings > General > Runtime. It is off by default, and enabling it requires a title-generation model:
- Same as task: The default option. Each new task uses the model actually selected for that task to generate its title.
- A specific model: Used only to generate the title asynchronously; it does not change the model used by the task itself.
Title generation never blocks task submission. If a selected title model is no longer available, Wework skips title generation and still creates the task normally.
Knowledge Base Contextβ
Click the context button to add knowledge bases:
- Click the "#" button - Opens the context selector
- Select knowledge bases - Check the ones to add
- Confirm selection - Knowledge bases appear as tags
Skill Selectionβ
If the agent supports skills:
- Click the skill button - Opens skill selector
- Select skills - Check the needed skills
- Or use "/" command - Type
/in the input box to trigger skill selection
Step 5: Enter Task Description and Sendβ
- Type your task description in the input box - Clearly describe your requirements
- Add attachments (optional) - Use the attachment button, or drag files from Finder directly into the Wework input box
- Press Enter to send - Or click the send button
- Wait for response - Agent starts processing and streams results
Attach a Sketchβ
Select Draw from the Wework composer's + menu, or type @ and select Draw, to open the Excalidraw canvas. It supports freehand drawing, text, shapes, erasing, colors, stroke widths, and undo/redo.
Click Add to chat to export the sketch as a PNG with a white background and add it to the composer's attachments. Preview, remove, or send it with your message. Empty drawings cannot be attached. Canceling adds no attachment; failed exports preserve the sketch for retry. The canvas and fonts are bundled with the desktop app, so drawing and export do not require an external service.
Add Files and Selected Text from the Workspaceβ
In Wework desktop, you can reuse context directly from the right workspace and bottom terminal:
- Drag a file or folder from the right file tree into the composer to add it to the current conversation as a workspace path reference.
- Select text in a code or Markdown file preview, file editor, or terminal to show the Add to conversation action beside the selection. Click it to insert the text into the current composer.
- You can also drag selected text into the composer. The desktop system drag panel appears only after dragging starts and closes when the drag ends or is cancelled.
Task Execution Flowβ
Execution Stagesβ
1. Task Initializationβ
- System creates task record
- Allocates execution container
- Clones target repository into container
2. Code Analysisβ
- AI analyzes repository structure
- Understands existing code patterns
- Plans implementation approach
3. Code Implementationβ
- AI uses tools to read, edit, create files
- Executes necessary commands (e.g., install dependencies, run tests)
- Shows progress in real-time in the Workbench
4. Code Commitβ
- AI creates feature branch
- Commits code changes
- Generates commit messages
5. Task Completionβ
- Generates task summary
- Shows file change statistics
- Provides option to create PR
Task Status Managementβ
Task Statesβ
| Status | Description | Actions |
|---|---|---|
| PENDING | Waiting to execute | Can cancel |
| RUNNING | Currently executing | Can stop |
| COMPLETED | Execution finished | Can view results, create PR |
| FAILED | Execution failed | Can retry |
| CANCELLED | Was cancelled | Can recreate |
Wework Model Rate-limit Waitingβ
When the local model proxy receives HTTP 429 or Codex reports a model rate limit and retries automatically, the conversation immediately shows βModel rate limited. Waiting to retryβ¦β. Desktop and mobile sidebars replace the running spinner with a waiting clock and the label βRate limited, waiting to retryβ. The current response is waiting for the model service, not finished or frozen.
You can still stop the response. Follow-up messages keep their existing queue behavior and are not sent early because of the waiting display. The indicator clears when model output resumes; an exhausted retry becomes a failure. Ordinary network reconnection is not labeled as rate limiting, and rate limiting does not offer network proxy configuration.
The UI does not invent a countdown when the model protocol provides no precise retry time.
Subagent model rate limits also appear in their owning task. When multiple subagents are waiting, the indicator remains until all of them stop waiting; progress from the parent task does not clear it early.
Concurrent model requests in the same thread have independent wait lifetimes; one recovering request does not clear another request's wait. Proxy waits and native Codex retries are also tracked independently, retaining the rate-limit indicator while any request remains rate limited.
If a retry error omits its thread identity, progress from the current root conversation clears that wait. Subagent progress does not clear the root wait or affect other model requests.
Stopping a Taskβ
If you need to stop a running task:
- Click the stop button - In the input area or task details
- Confirm stop - Task will be marked as cancelled
- View partial results - Completed code changes are preserved
Retrying a Taskβ
If a task fails:
- View error message - Understand the failure reason
- Click retry button - Re-execute the task
- Or modify and retry - Adjust task description and resend
After the retry request is accepted, the failed message turn is removed from the conversation. When the retry succeeds, the conversation keeps the original user message and the new successful response without retaining the old failure card or leaving an empty response turn. Wework applies the same rule when the task is reopened.
Sending Follow-ups While Runningβ
While a Wework task is running, you can choose among three send modes:
- Send after current response: queues the message until the current turn finishes. Press
Enter. - Guide current response: keeps the current turn running and lets Codex apply the instruction at its next safe input boundary. Press
Command/Ctrl + Enter. - Interrupt and send now: stops the current turn and immediately sends the message as a new turn in the same conversation. Press
Command/Ctrl + Shift + Enter.
After entering a message, use the down arrow on the right side of the send button to open the menu. The clock means wait for the current response, the turning arrow means guide the current response, and the lightning bolt means interrupt and send immediately. Interrupting does not roll back file changes or other tool side effects that already occurred. Regular queued messages remain queued.
The queue sends messages serially from top to bottom. A turn-terminal event alone does not trigger delivery; Wework sends the first queued message only after the local Executor task snapshot confirms that execution is idle. After submission, it also waits for that message's new turn to confirm that it started before allowing another queued message to send, preventing concurrent submissions. When several messages are queued, drag the handle on the left of a message to reorder the list with live feedback. Stopping the current response also pauses the queue instead of immediately sending the next message. Selecting Continue sending restores the guidance state and sends the first queued message immediately.
Authoritative conversation history from the Executor can also confirm idle execution. Running snapshots from an already completed older turn cannot overwrite a later turn's state, mark an idle task as running again, or block queued messages. A new turn still requires an actual send, runtime event, or Executor-confirmed state.
If you submit new composer text while the queue is paused, Wework asks how to handle the existing queue:
- Keep and continue: sends the new composer message first, then continues the preserved queue; the composer is cleared after submission.
- Clear queue: removes the existing queue and sends only the new composer message.
- Cancel: sends nothing and preserves both the composer and the queue.
The temporary sidebar conversation supports the same running send modes as the main conversation. A message sent normally while the current response is running enters the pending queue and is sent automatically after the response finishes. Selecting Guide current response applies the message to the same active turn in the temporary conversation instead of creating a regular follow-up turn. The sidebar does not surface βtask is already runningβ as a send failure while a message is queued; from its queue card, you can cancel or edit the pending message, or send it as guidance.
Advanced Featuresβ
Continue Conversationβ
After task completion, you can continue chatting with the agent:
- Send new message in the same task - Agent continues working with previous context
- Request modifications - e.g., "Please rename the function to createUser"
- Request additions - e.g., "Please add unit tests"
View Execution Detailsβ
View detailed execution information in the Workbench:
- Execution Timeline: See tools used by AI and execution order
- Tool Duration: Each command or tool row shows its own precise duration; the tool-group header does not count the turn's reasoning and waiting time as tool duration
- Reasoning Summary: Shows the latest model-provided reasoning summary while work is active and keeps it expandable after completion
- Commit History: View all code commits
- File Changes: See specific modifications for each file
Create Pull Requestβ
After task completion, you can directly create a PR:
- Click "Create PR" button - In the Workbench or task menu
- Fill in PR information - Title, description, etc.
- Submit PR - System creates PR in GitHub/GitLab
Export Taskβ
Export task conversation history and code changes:
- Click export button - In the task menu
- Choose format - Markdown or JSON
- Download file - Save to local
Viewing Codex-generated Visualizationsβ
When Codex creates an HTML visualization in the task workspace and references it in its response, Wework displays the chart or interactive page directly in that response. You do not need to copy a file path or open a separate browser.
- Wework supports the latest visualize content reference, such as
ξvisualizeξ{"path":"/absolute/path/output/chart.html"}ξ. The absolute path does not need to appear in the current response's file changes, and the containing directory is unrestricted, so HTML generated in workspace output folders or Wework attachment drafts can be displayed directly. - The legacy
::codex-inline-vis{file="chart.html"}directive remains supported. Legacy directives resolve relative paths or unique file names only from files created or modified in the current response, including fragments organized by date and thread under.codex/visualizations/. - The visualization runs in a script-isolated iframe and cannot access the Wework page.
- Wework's desktop backend reads the HTML before passing it to the isolated iframe. Only regular UTF-8
.html,.htm, or.xhtmlfiles up to 5 MB are accepted; symbolic links, malformed references, paths containing parent traversal, and directives inside code fences remain normal text or are not loaded. - Wework wraps HTML fragments in a UTF-8 visualization host, supplies the Codex visualization theme variables, and automatically sizes the iframe to the fragment content.
Mermaid and PlantUML Diagramsβ
When a model emits a mermaid, mmd, plantuml, or puml code block, Wework renders the diagram directly while the response is streaming. No intermediate HTML file is required. The diagram follows the active light or dark theme and automatically fits the conversation width.
Two actions appear in the lower-right corner:
- Copy image writes the current diagram to the system clipboard as a PNG.
- Save image opens the system save dialog and saves the PNG locally.
The workspace file panel also previews .mermaid, .mmd, .plantuml, and .puml files directly with the same copy and save actions.
Cleaning Stale Runtimesβ
Admins can manually clean up code task runtimes that have not been updated for a long time to release execution container resources. Cleanup only deletes runtime Pods or containers. It does not delete Task records, conversation history, or code changes.
Use this when:
- A task has stopped or finished, but its execution environment still consumes resources
- A runtime has had no activity for a long time and should be reclaimed by Task ID
- You want to run a dry run first, then perform the actual cleanup
Cleanup rules:
- Cleanup targets one Task ID at a time and is not a full cleanup action from the user interface
- Runtimes newer than the configured inactive duration are not deleted
- Tasks with
preserveExecutorenabled are not cleaned up - Device executors are not deleted by this cleanup entrypoint
- Task history remains available after cleanup, but rerunning work allocates a new runtime
For API details, see Runtime Cleanup in the developer documentation.
Common Issuesβ
Q1: Task stuck in PENDING status?β
Possible causes:
- No available execution containers
- Repository access permission issues
- Git token expired
Solutions:
- Check if system resources are sufficient
- Verify Git token is valid
- Check repository access permissions
Q2: Code commit failed?β
Possible causes:
- Branch protection rules
- Insufficient permissions
- Network issues
Solutions:
- Check target branch protection rules
- Confirm Git token has write permissions
- Retry the task
Q3: AI modified the wrong files?β
Solutions:
- Explicitly specify file paths to modify in the task
- Provide more detailed context information
- Use knowledge base to provide project structure documentation
Q4: How to make AI follow project coding standards?β
Solutions:
- Add
.cursorrulesor.windsurfrulesfile in repository root - Explicitly state coding standards in task description
- Use knowledge base to provide coding standards documentation
Q5: Task execution taking too long?β
Possible causes:
- Task scope too large
- Need to install many dependencies
- Network latency
Solutions:
- Split large tasks into smaller ones
- Use pre-configured base images
- Check network connection
Related Resourcesβ
- Overview - AI Coding feature overview
- Spec Clarification - Requirement clarification feature
- Agent Settings - Configure code agents
Efficiently manage your code tasks and let AI be your programming assistant! π