What you will learn
- Work with assistants on development tasks in Bosi, and use plugins and delivered files.
- Use projects in Bosi conversations and understand how project conversations are switched.
- Turn on the local Shell through “Create your Bosi”, or use an assistant with Desktop Shell enabled.
- Configure the local terminal and understand the three execution permissions.
- Approve or deny local commands requested by an assistant in a conversation.
- Open coding tools on the cloud computer, and understand what labels such as “Model compatible” mean.
- Distinguish three execution locations: local commands, server sandbox commands, and the cloud computer.
- Connect Bosi to a self-hosted or local development Xpert service.
- Configure automations such as schedules for an assistant.
Three ways to develop
You can combine these approaches: work on the task in a project conversation, have the assistant request local commands when it needs to work on your computer, and open coding command-line tools on the cloud computer when you need them.
Before you begin
The features and limits of projects, the local Shell, and the cloud computer may change between versions. Follow the on-screen messages of the version you use.
Work with an assistant on development tasks
After you select an assistant in Bosi, the chat area on the right provides messages, attachments, conversation history, tools, skills, connectors, and the Workbench. Common ways to handle development tasks include:- Describe the goal and let the assistant break it down: State the work to be done and how to verify it, for example, “Check the directory structure of the current project and explain how to run the tests.”
- Upload attachments: Send files that need analysis to the assistant as attachments.
- Select plugins: In Discover & add → Plugins, you can view the plugins installed for your tenant or organization and the capabilities they include. Installed plugins can be selected directly from the conversation’s Plugins menu; required connections are still configured and authorized through the existing flow.
- View delivered files: After the assistant generates a file, click the delivery card in the conversation to preview the version saved at delivery and download it. Formats that cannot be previewed can be downloaded directly.
Approach 1: Develop with projects
Projects are a collaboration feature of the Xpert platform. A project brings digital experts, toolsets, file resources, and conversation history together, so the participating agents can complete tasks based on shared files and project-level instructions. For creating projects and managing their members, files, toolsets, and execution modes, see Project.Use projects in Bosi
Bosi’s chat area embeds Xpert ChatKit and enables the projects feature in the composer. You can therefore use projects directly in Bosi conversations without switching to the web app. The project-related buttons, menus, and confirmation steps are provided by ChatKit; their names and locations depend on the connected ChatKit version. When developing with a project, we recommend that you:- Upload materials such as requirement documents and API descriptions as project files, so that all agents in the project can read them.
- Add the toolsets you need to the project, and set project-level instructions, such as coding conventions, directory conventions, and commit requirements.
- Describe the development goal in a project conversation, and let the assistant break down the task and move it forward step by step.
- When you need to inspect code or run commands on your computer, use the local Shell described below.
Open projects and switch conversations
- When you open a project from the Workbench or a conversation, Bosi switches to that project’s conversation and uses the assistant bound to the project.
- When you open a past conversation that belongs to a project, Bosi continues it under that conversation’s project and assistant.
- Project access is checked by the server. Without access, opening the project fails, and Bosi keeps the current assistant; it does not open the project with a different assistant.
- When you reopen a conversation, project actions in it that are still awaiting confirmation are kept, so you can continue handling them.
Approach 2: Develop with the built-in local Shell
Bosi has a built-in “This computer Shell” (shown in Settings as Local terminal). After the assistant requests a command in a conversation, the command runs on your Mac, and its output and exit code are returned to the conversation. The local Shell does not provide an interactive terminal window where you type commands yourself. Every command is initiated by the assistant, runs in a fresh non-interactive shell, and is approved according to the execution permission you set. To use coding command-line tools directly, use the coding tools on the cloud computer, described in Approach 3 below.Step 1: Turn on the local Shell for an assistant
You can give an assistant local command capability in either of the following ways. Turn it on through “Create your Bosi” When the connected server supports it and you have not yet created a personal Bosi in the current organization, the main area shows Create your Bosi after you sign in:- Read the introduction and click Continue.
- In Make Bosi more helpful, choose the capabilities you need and connect accounts, or click Set up later.
- In Choose where Bosi can work, turn on the capabilities you need:
- Bosi’s computer: Work with a server computer and its applications. It is on by default when the server provides this capability.
- This computer Shell: Run local commands with the existing command approvals. It can be turned on only in the native macOS app.
- Choose the assistant model. When Bosi’s computer is on, choose a compatible model with vision and tool calling.
- Click Create Bosi. If initialization is interrupted, click Resume setup to continue.
Step 2: Configure the local terminal
Open Settings → Local terminal to manage command execution on this computer:
After changing the computer name, Shell, default working directory, or command search path, click Apply Shell settings. These changes are applied separately in the local terminal and are not affected by Save settings at the bottom of the Settings page. Applying Shell settings disconnects the current connection and revokes any authorizations that have not run yet. The next command request reconnects with the new settings.
The three execution permissions differ as follows:
Execution permissions apply only to the current account, the current organization, and this computer. Unless you fully trust the assistants in this organization that may request local commands, keep Ask for every command.
No manual connection or per-conversation authorization is needed: Bosi connects automatically when an assistant requests a local command. The local terminal page shows the current status, such as connects when needed, connecting, or connected.
Step 3: Request and approve a local command
In a conversation with an assistant that has the local Shell turned on, send:- After the assistant requests a local command, an approval card appears in the message. It shows the command to run, the computer, the working directory, and an access notice.
- Review the command. The command does not run until you make a choice.
- On the card, choose to allow this one execution, or deny it. The permissions entry on the card opens the Local execution permissions window, which has the same content as the local terminal settings.
- After you approve, the command runs on your computer, and its output and exit code are returned to the assistant. The next command requires approval again.
- If you deny, the command does not run. The assistant should stop this operation and does not fall back to a server Shell to run it instead.
bosi-test.txt in the test directory and confirm that its content is what you expected. Rely on the actual file and exit code, not only on the assistant’s text description.
The conversation header can show the computers the assistant can use and their status. When you open the local computer from a conversation, Bosi also opens the Local execution permissions window.
View and stop commands
In Settings → Local terminal or the Local execution permissions window, you can view recent commands, including the working directory, status (Pending, Running, Stopping, Succeeded, Failed, Cancelled, Timed out, Rejected, Unknown), and recent output. To interrupt a running command, click Stop command. The Unknown status means Bosi cannot confirm whether the command completed. Bosi does not run the command again; check the actual result yourself before deciding whether to request it again.Understand how local commands run
Security boundaries- Commands run with the permissions of the operating-system user you are signed in as. The working directory is only a starting directory, not an isolated sandbox, and it does not restrict file access.
- Command output is sent to Xpert and stored on the server. Output may contain business data, so avoid running commands that print sensitive information.
- Each command runs in a fresh, non-interactive shell that inherits only a small set of environment variables. It does not inherit platform account or device credentials.
- There is no interactive terminal (PTY), interactive input, persistent Shell session, file synchronization, or local agent runtime. Commands that require interactive input cannot work properly.
When it stops
- After you close the macOS window, the app and the local terminal keep running.
- Switching organizations, changing the service connection, signing out, or quitting the app stops the local terminal.
- After the app restarts, the selected execution permission is kept, but temporary authorizations are not.
- Expired approvals cannot run. Deny or stop that request, then make a new one.
Distinguish the three execution locations
One assistant can have several execution capabilities at the same time. When you ask, state where you want the work to run, and check the execution location in the returned result.
When verifying local execution, a result from the server sandbox does not count as local execution. Cloud computer tasks require a model with vision and tool calling. Whether your organization offers this capability depends on the server configuration.
Approach 3: Develop with the cloud computer’s coding tools
The cloud computer is a private Ubuntu desktop that the server provides for you, which you and your Agents can operate at the same time. Coding tools on the cloud computer panel lists the coding command-line tools (CLIs) that this conversation can use, such as Codex, OpenCode, Aider, Claude Code, Qwen Code, Kimi Code, and CodeBuddy. The tools actually listed depend on your organization’s configuration. Unlike the local Shell, coding tools run on the cloud computer and use the current conversation assistant’s model, and you can open them directly to work on code.Connect to and operate the cloud computer
- Open the Computer view in the assistant’s Workbench to go to the Cloud computer panel.
- Click Connect to view. After you connect, People and Agents share this desktop appears above the desktop, and a control bar appears at the bottom.
- To operate the desktop, click Start interacting in the control bar. The left side of the control bar shows You can interact.
- To only watch, click View only.
Open a coding tool
- Click the terminal icon in the control bar to open Coding tools.
- The top of the panel shows the hint “Uses this conversation’s models. Runs continue when you release control.”, along with the current assistant, model, and working directory.
- Find the tool you need in the list, check its labels, and click Open.
Understand the tool labels
Each tool shows three labels:
Only tools labeled both Installed and Model compatible can be opened.
Coding tools do not use a separate model. They use the current conversation’s model, and that model must support the protocol the tool uses. When a tool is labeled Model incompatible, it cannot use this conversation’s model and cannot be opened even if it is installed. For example, when Codex is labeled Model incompatible, running it in this conversation may return the error “requested model is not available for this execution”. To use such a tool, select a model compatible with it for the assistant and try again.
The model is provided by the platform for each conversation, so you do not need to configure your own model API key on the cloud computer.
Manage coding sessions
After you open a tool, its coding session appears in the list at the bottom of the panel, with the tool name, status, assistant and model, and working directory. Statuses include Starting, Running, Stopping, Exited, and Status unknown. When there are no sessions yet, the list shows No coding sessions.- To end a session, click Stop next to it. Exited sessions no longer show a Stop button.
- After you click View only to release control of the computer, coding tasks can keep running.
Recommended instruction for coding assistants
The cloud computer’s default image includes the built-in cloud coding skill/opt/xpert/skills/cloud-coding/SKILL.md, which provides command-line-first guidance for tasks, approvals, recovery, and delivery. To have the assistant follow this workflow for development tasks, add the following to the instructions in the assistant’s Edit profile, and then click Save & publish:
sandbox_shell tool provided by the Sandbox Shell middleware. If you turned on Bosi’s computer when creating Bosi, Bosi’s instructions already include guidance for the cloud coding skill, so you do not need to add it again.
Connect to your own Xpert service
For development or testing, you can connect Bosi to a self-hosted or locally running Xpert service:- Click Connection settings on the sign-in screen, or open Settings → Service connection after you sign in.
- Enter the API service URL, Xpert web URL, and ChatKit URL. Remote services require HTTPS;
localhostaddresses on your own computer may use HTTP. - Wait for the page to check the URLs and certificates. For a self-signed certificate you trust, turn on Allow untrusted service certificates. This setting also applies to the local terminal’s connection to the configured API service.
- Save the settings and sign in again.
- The local terminal establishes a WebSocket connection through the API service’s Socket.IO endpoint (
/socket.io/). The reverse proxy must allow WebSocket upgrades. - Your computer does not open any listening port; Bosi initiates the connection.
- When upgrading, deploy matching versions of the server, Bosi, and ChatKit together. Updating only Bosi does not give an older ChatKit new capabilities.
Configure automations
Automations let an assistant start working at a specific time, on a schedule, or when an event happens, reusing the assistant’s published instructions, skills, tools, and connectors. Managing automations requires a published assistant and workspace edit access.- Hover over the assistant’s avatar in the sidebar to open the assistant profile panel, and switch to Automations.
- Create a new automation.
-
Choose a trigger:
Triggers other than Schedule require installing a provider plugin of that type in Xpert first.
- Set the conditions and scope. For a schedule, choose Every hour, Every day, Every weekday, or Every week, or use Custom schedule and enter a cron expression (minute, hour, day of month, month, day of week). Schedules follow the Xpert server’s timezone.
- Optionally enter additional instructions, for example, “Summarize yesterday’s merged code changes and open issues.” The assistant’s role, skills, tools, and connectors are inherited automatically and do not need to be configured again.
- Review the configuration and save it.