Skip to main content

​
🚀 Features

  • Custom tool permission approvals in App Builder chat You can now attach custom tools to an App Builder chat and approve each tool call the coding agent makes, directly in the chat.
    • A new Tools tab in the attach context popup lets you browse and search your workspace’s custom tools and add them to a prompt
    • When the coding agent wants to run a tool action, a permission card shows the tool and action with Allow Once, Allow for this Chat, and Deny options
    • Actions you allow for the chat run automatically afterward and are marked “Allowed to run automatically for this chat.” Select Require approval? to revoke the grant and get prompted again.
    • Pending permission requests are restored when you reconnect to an active chat
    • Custom tools are now enabled by default. Self-hosted deployments can turn them off by setting AGENTIC_CODING_CUSTOM_TOOLS_ENABLED=false.

​
🛠️ Chores

  • Custom tools support in Agentic Coding sessions The coding agent can now discover, inspect, and run your workspace’s custom MCP tools during an Agentic Coding session. Each tool call requires your approval.
    • Add up to 10 workspace tools to a prompt’s context with the tools field
    • The coding agent can list the tools available to it, look up a tool’s actions, and call those actions
    • List pending permission requests with GET .../sessions/{id}/permissions and answer them with POST .../sessions/{id}/permissions/{request_id}/reply, using a reply of once, always, or reject
    • A once approval applies to a single call and expires after 5 minutes. An always approval applies to every later call of that tool action in the session.
    • Revoke an always approval with DELETE .../sessions/{id}/permissions/revoke, passing tool_id and tool_action
    • Running, approving, or revoking a tool requires permission to update tools, so viewers cannot run tools
    • An always approval stops applying if the user who granted it loses permission to update the tool
    • An hourly job removes used and expired one-time approvals
    • The workspace tools list API now supports filtering by enabled status, along with pagination
    • The feature is on by default. Self-hosted deployments can turn it off by setting AGENTIC_CODING_CUSTOM_TOOLS_ENABLED=false.
    • Tool and streaming connections to private or reserved network addresses are blocked. Self-hosted deployments can exempt specific ranges with SSRF_ALLOWED_CIDRS.
    • Streamed tool responses are capped at 1 MiB, and connection error messages no longer include raw response bodies
  • Persistent tool permissions for Agentic Coding sessions Added the underlying database table and model that persist per-session tool permission decisions for Agentic Coding, so that “allow” choices made during a session are remembered.
    • Introduced a new agentic_coding_tool_permissions table that links a session, a tool, and the user who granted access, scoped to a workspace
    • Each session and tool combination is unique, preventing duplicate permission records
    • Tools must belong to the same workspace as the session before a permission can be granted
    • Permissions are automatically removed when the associated session, tool, or granting user is deleted
  • App cloning for Agentic Coding apps Enterprise users can now asynchronously clone an Agentic Coding app into one or more workspaces, with status tracking for progress and failures.
    • POST /enterprise/api/v1/agentic_coding/apps/{app_id}/clones starts a clone job for the given name and workspace_ids, returning a clone_request_id
    • GET /enterprise/api/v1/agentic_coding/clones/{clone_request_id} reports the clone status as succeeded, failed, or in_progress, along with the source app and cloned apps
    • Cloning includes sandbox state and applicable database, storage, and secret resources, and reuses sandbox snapshots when available
    • Parallel clone operations are bounded by a configurable limit, defaulting to five
    • Administrators and members can clone apps; viewers cannot
    • Workspace access is validated, duplicate jobs are prevented, stale requests are recovered, and cleanup and rollback are handled on failure
  • Cleanup of GitHub source control for Agentic Coding apps Refined the GitHub integration for Agentic Coding apps, tightening token rotation, deploy change detection, and commit message handling.
    • GitHub tokens for connected installations are now refreshed by a scheduled daily rotation job that backs off and reschedules when GitHub rate limits are hit
    • Deploys now record the last commit hash alongside the code hash, improving detection of pending changes when publishing an app
    • Commit messages for automatic session pushes are derived from a structured commit-intent emitted by the coding agent, with a consistent AppBuilder Commit prefix
    • New prompts are blocked while a session has an unresolved merge conflict, and conflicts can be resolved with “ours” or “theirs” strategies
    • Git and webhook endpoints are now rate limited to protect against request floods
    • Prompts now record the user who created them
  • Backwards compatibility for older Agentic Coding sandbox images Agentic Coding sessions now verify that Git is available in the sandbox before starting the coding service.
    • Sandboxes built from older images that lack Git get it installed automatically during session setup
    • The check runs whenever a sandbox is created, cloned, or resumed, improving session startup reliability
  • First-session prompt metadata on the get app API The GET app API for Agentic Coding apps now optionally returns metadata about the first prompt session, making it easier to link back to the initial prompts.
    • Adds a last_prompts_link attribute that includes the first session ID and pagination info
    • Prompt listings are ordered by prompt start time, falling back to creation time when unavailable, with a deterministic tiebreaker
    • Pagination reports a fixed page size of 100 prompts
  • Persisted tool permission decisions for Agentic Coding sessions Added a data model for recording which tools a user has allowed for an Agentic Coding session, laying the groundwork for reusing tool-approval decisions across prompts.
    • Introduces an agentic_coding_tool_permissions table linking a session, a tool, and the user who granted access
    • Enforces one permission per tool per session and requires the tool to belong to the same workspace as the session
    • Permissions are removed automatically when the session, tool, or granting user is deleted
  • API to retrieve Git session events for Agentic Coding sessions Added an API endpoint that returns the Git activity history of an Agentic Coding session, making it easier to audit what happened during a session.
    • Events are returned in chronological order with details, metadata, delivery ID, and creation timestamp
    • Sensitive values in event metadata are automatically redacted
    • Results support pagination with a maximum of 100 items per page
    • Access is restricted to authorized workspace members and valid sessions
    • Requests are rate limited to 60 per minute per IP
  • Custom tools support in Agentic Coding sessions Agentic Coding sessions can now discover, inspect, and run workspace custom tools, with per-call permission requests and approvals.
    • Coding agents can list available custom tools, look up tool actions, and execute tool calls from within a session
    • Prompts can include up to 10 workspace tools in their context, with validation and access controls
    • New session endpoints list pending permission requests, reply to them, and revoke granted permissions
    • Tool calls can be approved once or always for the session, and a recurring job purges stale tool permissions
    • Running a custom tool requires the same permission as editing a tool, so viewers cannot run tools
    • Workspace tool listings now support filtering by enabled status and pagination
    • Custom tool support is gated by the AGENTIC_CODING_CUSTOM_TOOLS_ENABLED environment variable
    • Tool and streaming connections to private or reserved network addresses are blocked, with exemptions configurable through SSRF_ALLOWED_CIDRS
    • Streamed responses are limited to 1 MiB, response bodies are removed from user-facing connection errors, and secrets in tool configuration are masked more thoroughly