Repository navigation
docs: auto-sync cloud-agent with merged PRs (through 2026-11-04) #15141
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from 7 commits
f575fc2
4249b41
811a9d8
a10999c
d841a4b
b43b5d9
c995f82
cdda06a
907b3b9
c71bd73
bf2084e
9080230
2bf9656
d514059
98dd158
9dd4b80
2e66333
80ace67
f7fffec
cbf7055
cf6ad8e
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -61,7 +61,7 @@ On the **General** tab: | |
| - **Default sandbox** — the sandbox for new sessions when a repository has no override. The dialog names the sandbox that **Platform default** resolves to, so you can see what a session uses when nothing else applies. | ||
| - **Repository overrides** — set or clear a sandbox and an [agent environment profile](#agent-environment-profiles) for an individual repository. | ||
|
|
||
| The **Profiles** tab hosts the full profile manager: the profile list on the left and a detail pane on the right with **Overview**, **Variables**, **Setup**, **Slash Cmds**, **MCP**, **Skills**, and **Agents**. | ||
| The **Profiles** tab hosts the full profile manager: the profile list on the left and a detail pane on the right with **Overview**, **Variables**, **Setup**, **Slash Cmds**, **MCP**, **Skills**, **Agents**, **Instructions**, and **Import**. | ||
|
|
||
| Each change saves as you make it. In an organization, members see the settings read-only; only owners and admins can change them. | ||
|
|
||
|
|
@@ -138,6 +138,12 @@ Use the side-by-side toggle in the file viewer to switch between a unified diff | |
|
|
||
| These are saved snapshots, not a live view of the checkout. Diffs may be unavailable for binary, unsupported, or large files, or when there are too many changes to save in full. | ||
|
|
||
| ## Previewing a running app | ||
|
|
||
| You can preview a web app running inside a Cloud Agent session's sandbox. When a session serves an app on a port, the web interface shows a preview button and preview links, and selecting one opens the running app in a new browser tab. Each preview is served from its own hostname that targets the session's workspace and port, so different sessions and ports do not collide. | ||
|
|
||
| Preview is available to every Cloud Agent account. | ||
|
|
||
| ## Agent Environment Profiles | ||
|
|
||
| Agent environment profiles are reusable bundles of environment settings for cloud-agent sessions. A profile can include: | ||
|
|
@@ -150,6 +156,14 @@ Profiles are owned by either a user or an organization. Names are unique per own | |
|
|
||
| In the web app, manage profiles from the **Profiles** tab of the [Cloud Agent settings dialog](#choosing-where-sessions-run). | ||
|
|
||
| ### Importing a local configuration | ||
|
|
||
| You can import a local Kilo configuration ZIP into a profile to move your agents, slash commands, skills, and instructions into the cloud. Open the profile in the **Profiles** tab and use the **Import** tab. | ||
|
|
||
| Kilo validates the archive and shows a preview of what it contains before anything is saved. Review the preview, then confirm to replace the profile's agents, slash commands, skills, and instructions. Definitions that match keep their IDs, and definitions missing from the archive are removed; variables, setup commands, and MCP servers are not changed. If the archive is invalid — for example, it uses a reserved built-in agent name — Kilo shows the validation error and disables the import. | ||
|
|
||
| Imported instruction files appear on the profile's **Instructions** tab. | ||
|
|
||
| ## Environment Variables & Secrets & Startup Commands | ||
|
|
||
| You can customize each Cloud Agent session by also defining env vars and startup commands on the fly. These will override any Agent Environment Profile you've selected: | ||
|
|
@@ -254,12 +268,28 @@ For models that support it, webhook and scheduled triggers can set a **reasoning | |
|
|
||
| Triggers do not support manual env var or setup command overrides at this time. | ||
|
|
||
| ### Sandbox selection | ||
|
|
||
| When your account can choose a sandbox, the trigger form shows a **Sandbox** field. Choices are grouped by provider and filtered to the runtimes available for the selected repository, including the Cloudflare Containers runtime where it applies. **Automatic** keeps the default Cloud Agent routing. | ||
|
|
||
| Existing triggers keep any allocation they already have. Legacy allocations are not offered when you create a trigger or change its sandbox. | ||
|
|
||
| ### Run as webhook creator | ||
|
|
||
| By default, organization triggers run as the organization webhook bot. When you create an organization trigger, you can instead select **Run as webhook creator** so each session runs with your identity. Organization billing and repository scope stay with the organization. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. SUGGESTION: Mention that shared organization settings still apply This explains that each session runs with your identity, but not that organization profiles and repository settings remain shared and are resolved at run time. Members who can edit those settings can therefore affect what a creator-run session executes under your identity. One sentence about that trust boundary would help readers decide whether to opt in. |
||
|
|
||
| This is a create-time choice and cannot be changed later. Only you, the creator, can edit a creator-run trigger or run it on demand. Existing triggers keep using the organization webhook bot; create a new trigger to use creator mode. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. SUGGESTION: Clarify where "run it on demand" applies Creator-run mode also covers scheduled triggers, and only scheduled triggers have an invoke action — the section below states that webhook triggers have no invoke action. Consider saying that you can run a creator-run scheduled trigger on demand, so readers do not look for a Run action on creator-run webhook triggers. |
||
|
|
||
| Creator-run webhooks require shared-secret authentication. Set a header name and a secret of at least 16 characters when you create the trigger, and send the same header with every request. Kilo revalidates your account, the organization, and your direct membership before each delivery and retry. If that authorization fails, the request fails instead of falling back to the organization bot. | ||
|
|
||
| ### Scheduled Triggers | ||
|
|
||
| Scheduled triggers fire on a recurring schedule using cron expressions. You can configure them with a simple frequency picker (every 10 minutes, hourly, daily, weekly) or enter a raw cron expression for full control. Each trigger has a configurable timezone (default: UTC) and handles daylight saving time transitions automatically. | ||
|
|
||
| The minimum schedule interval is 10 minutes. Scheduled triggers use `{{scheduledTime}}` and `{{timestamp}}` as prompt template variables (webhook-specific variables like `{{body}}` are not available since there is no inbound HTTP request). | ||
|
|
||
| Scheduled triggers do not accept inbound requests. They run only from their schedule or from the invoke action described below. | ||
|
|
||
| ### Invoking a scheduled trigger on demand | ||
|
|
||
| To run an active scheduled trigger immediately, select the **Play** action on its row and confirm. When editing one, use **Save and invoke now** to save your changes before starting the run. Paused triggers cannot be invoked, and webhook triggers have no invoke action. | ||
|
|
@@ -317,6 +347,8 @@ You can reference data in a trigger’s prompt template using these placeholders | |
| - `{{scheduledTime}}` - the time the schedule fired (ISO string) | ||
| - `{{timestamp}}` - capture timestamp (ISO string) | ||
|
|
||
| Kilo expands placeholders in the prompt template once. A placeholder that arrives inside captured request data, such as `{{headers}}` within a webhook body, stays as literal text and is not expanded again. | ||
|
|
||
| {% callout type="warning" title="Security Considerations" %} | ||
| Care should be taken when deciding to use webhooks as they are susceptible to prompt injection attacks. Especially in scenarios where webhook payloads may contain untrusted input. At this time we recommend using webhooks only for trusted sources. | ||
| {% /callout %} | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SUGGESTION: Consider documenting who can reach a preview URL
This paragraph explains that each preview is served from its own hostname targeting the session's workspace and port, but it does not say whether that URL requires a Kilo sign-in or is reachable by anyone holding the link. Since the preview exposes a web app running inside the sandbox, one sentence about the access model (and whether previews should be treated as shareable/public) would help readers decide what they expose there.