dsyme · Feb 18, 2026 · Feb 18, 2026 · Feb 18, 2026 · Feb 18, 2026 · Feb 18, 2026
diff --git a/docs/slides/index.md b/docs/slides/index.md
@@ -426,10 +426,10 @@ flowchart TB
 
 ---
 
-# Security Layer 1: Agent Sandbox
+# Security Layer 1: Coding Agent Sandbox
 ## Isolated agent process
 
-**Agent Sandbox:**
+**Coding Agent Sandbox:**
 - Agent process runs in isolated container
 - Read-only permissions by default
 - No direct write access to repository

diff --git a/docs/src/content/docs/blog/2026-01-30-imports-and-sharing.md b/docs/src/content/docs/blog/2026-01-30-imports-and-sharing.md
@@ -153,7 +153,7 @@ The factory organized shared components into two main directories:
 
 **[`gh-aw.md`](https://github.com/github/gh-aw/tree/2c1f68a721ae7b3b67d0c2d93decf1fa5bcf7ee3/.github/workflows/shared/mcp/gh-aw.md?plain=1)** (12 imports)
 
-- GitHub Agentic Workflows MCP server
+- GH-AW as an MCP server
 - `logs` command for workflow debugging
 - Workflow metadata access
 

diff --git a/docs/src/content/docs/guides/editing-workflows.md b/docs/src/content/docs/guides/editing-workflows.md
@@ -145,9 +145,6 @@ tools:
 
 ## Expressions and Environment Variables
 
-> [!CAUTION]
-> Adding GitHub Actions expressions (`${{ ... }}`) in the markdown body does NOT require recompilation, but they are subject to security validation.
-
 ### Allowed Expressions
 
 You can safely use these expressions in markdown without recompilation:

diff --git a/docs/src/content/docs/guides/getting-started-mcp.md b/docs/src/content/docs/guides/getting-started-mcp.md
@@ -90,9 +90,6 @@ mcp-servers:
     allowed: ["search_pages", "get_page"]
 ```
 
-> [!CAUTION]
-> For GitHub tools, always use `toolsets:` instead of `allowed:`. The `allowed:` pattern for GitHub tools is deprecated because tool names may change between versions.
-
 ## GitHub MCP Server
 
 The GitHub MCP server is built into agentic workflows and provides comprehensive access to GitHub's API.

diff --git a/docs/src/content/docs/guides/github-actions-primer.md b/docs/src/content/docs/guides/github-actions-primer.md
@@ -114,8 +114,7 @@ GitHub Actions implements a comprehensive security model designed to protect you
 
 ### Workflow Storage and Execution
 
-> [!CAUTION]
-> Workflows **must** be stored in the `.github/workflows/` directory on the **default branch** (typically `main`) or other protected branches to be active and trusted.
+Workflows **must** be stored in the `.github/workflows/` directory on the **default branch** (typically `main`) or other protected branches to be active and trusted.
 
 **Why workflows require main branch storage:**
 

diff --git a/docs/src/content/docs/guides/memoryops.md b/docs/src/content/docs/guides/memoryops.md
@@ -267,7 +267,7 @@ fi
 
 ## Security Considerations
 
-> [!CAUTION]
+> [!NOTE]
 > **Sensitive Data**
 >
 > Memory stores are visible to anyone with repository access:

diff --git a/docs/src/content/docs/guides/network-configuration.md b/docs/src/content/docs/guides/network-configuration.md
@@ -80,13 +80,13 @@ network:
 ```
 
 **Wildcard pattern behavior:**
+
 - `*.example.com` matches `sub.example.com`, `deep.nested.example.com`, and `example.com`
 - Only single wildcards at the start are supported (e.g., `*.*.example.com` is invalid)
 
 > [!TIP]
 > Both `example.com` and `*.example.com` match subdomains. Use wildcards when you want to explicitly document that subdomain access is expected.
 
-
 ## Protocol-Specific Filtering
 
 Restrict domains to specific protocols for enhanced security (Copilot engine with AWF firewall):
@@ -97,17 +97,12 @@ network:
   allowed:
     - defaults
     - "https://secure.api.example.com"   # HTTPS-only
-    - "http://legacy.internal.com"       # HTTP-only (legacy systems)
+    - "http://legacy.internal.com"       # HTTP-only
     - "example.org"                      # Both protocols (default)
 sandbox:
   agent: awf  # Firewall enabled
 ```
 
-**Use Cases:**
-- **HTTPS-only**: External APIs, production services
-- **HTTP-only**: Legacy internal systems, development endpoints
-- **Mixed**: Gradual HTTP → HTTPS migration
-
 **Validation:** Invalid protocols (e.g., `ftp://`) are rejected at compile time.
 
 See [Network Permissions - Protocol-Specific Filtering](/gh-aw/reference/network/#protocol-specific-domain-filtering) for complete details.

diff --git a/docs/src/content/docs/guides/upgrading.md b/docs/src/content/docs/guides/upgrading.md
@@ -148,13 +148,6 @@ Review changes with `git diff .github/workflows/` to verify that deprecated fiel
 
 Typical migrations include `sandbox: false` → `sandbox.agent: false`, `daily at` → `daily around`, and removal of deprecated `network.firewall` and `safe-inputs.mode` fields. Use `git diff --word-diff` for detailed comparison.
 
-> [!CAUTION]
-> Breaking Changes
->
-> **`timeout_minutes` Removed:** The underscore variant `timeout_minutes` has been completely removed from the schema. Workflows using this field will fail compilation. Use `timeout-minutes` (with hyphen) instead.
->
-> **`sandbox: false` Changed:** Top-level `sandbox: false` is no longer supported. Use `sandbox.agent: false` instead to disable only the agent firewall. The MCP gateway remains enabled and cannot be disabled. The `gh aw fix` command includes a codemod to automatically migrate this change.
-
 ## Step 5: Verify Compilation
 
 The upgrade automatically compiles workflows. To validate specific workflows, run `gh aw compile my-workflow --validate`. Common issues include invalid YAML syntax, deprecated fields (fix with `gh aw fix --write`), or incorrect schedule format. See the [schedule syntax reference](/gh-aw/reference/schedule-syntax/) for details.

diff --git a/docs/src/content/docs/patterns/siderepoops.mdx b/docs/src/content/docs/patterns/siderepoops.mdx
@@ -187,7 +187,7 @@ tools:
 
 Available toolsets: **repos** (files, code, commits, releases), **issues** (list/search/read), **pull_requests** (list/search/read), **actions** (workflow runs/artifacts), and **context** (repository metadata).
 
-> [!CAUTION]
+> [!NOTE]
 > GitHub tools with `mode: local` (Docker-based) can only access the repository where the workflow is running. Always use `mode: remote` for SideRepoOps.
 
 ## Private Repository Access

diff --git a/docs/src/content/docs/patterns/trialops.md b/docs/src/content/docs/patterns/trialops.md
@@ -43,9 +43,7 @@ Installs and runs the workflow in a specified repository. All outputs are create
 gh aw trial githubnext/agentics/my-workflow --repo myorg/test-repo
 ```
 
-> [!CAUTION]
-> Production Risk
-> Creates real issues and PRs in the target repository. Only use with test repositories.
+This creates real issues and PRs in the target repository. Only use with test repositories.
 
 ### Logical Repository Mode (`--logical-repo`)
 

diff --git a/docs/src/content/docs/reference/command-triggers.md b/docs/src/content/docs/reference/command-triggers.md
@@ -54,17 +54,9 @@ Now analyzing the content...
 
 This feature enables command aliases and grouped command handlers without workflow duplication.
 
-> [!NOTE]
-> **Deprecated Syntax**
-> 
-> The `command:` trigger field is deprecated. Use `slash_command:` instead. The old syntax still works but will show a deprecation warning.
-
 This automatically creates issue/PR triggers (`opened`, `edited`, `reopened`), comment triggers (`created`, `edited`), and conditional execution matching `/command-name` mentions.
 
-> [!CAUTION]
-> **Command Position Requirement**
-> 
-> The command must be the **first word** of the comment or body text to trigger the workflow. This prevents accidental triggers when the command is mentioned elsewhere in the content.
+The command must be the **first word** of the comment or body text to trigger the workflow. This prevents accidental triggers when the command is mentioned elsewhere in the content.
 
 You can combine `slash_command:` with other events like `workflow_dispatch` or `schedule`:
 

diff --git a/docs/src/content/docs/reference/faq.md b/docs/src/content/docs/reference/faq.md
@@ -295,53 +295,15 @@ See [Pull Request Creation](/gh-aw/reference/safe-outputs/#pull-request-creation
 
 This is expected GitHub Actions security behavior. Pull requests created using the default `GITHUB_TOKEN` or by the GitHub Actions bot user **do not trigger workflow runs** on `pull_request`, `pull_request_target`, or `push` events. This is a [GitHub Actions security feature](https://docs.github.com/en/actions/security-for-github-actions/security-guides/automatic-token-authentication#using-the-github_token-in-a-workflow) designed to prevent accidental recursive workflow execution.
 
-**Why GitHub implements this protection:**
-
 GitHub Actions prevents the `GITHUB_TOKEN` from triggering new workflow runs to avoid infinite loops and uncontrolled automation chains. Without this protection, a workflow could create a PR, which triggers another workflow, which creates another PR, and so on indefinitely.
 
-**Workarounds:**
-
 If you need CI checks to run on PRs created by agentic workflows, you have three options:
 
-**Option 1: Use a Personal Access Token (PAT)**
-
-Configure your workflow to use a PAT instead of `GITHUB_TOKEN`. This allows PR creation to trigger CI workflows:
+**Option 1: Use different authorization**
 
-```yaml wrap
-# In your workflow frontmatter
-env:
-  GH_TOKEN: ${{ secrets.PERSONAL_ACCESS_TOKEN }}
-```
+Configure your [`create-pull-request` safe output](/gh-aw/reference/safe-outputs/#pull-request-creation-create-pull-request) to use a PAT or a GitHub App. This allows PR creation to trigger CI workflows.
 
-The PAT must have `repo` scope (or `public_repo` for public repositories only) and should belong to a service account or automation user rather than a personal account.
-
-> [!CAUTION]
-> Using a PAT bypasses GitHub's recursive workflow protection. Ensure your CI workflows cannot trigger the PR creation workflow to avoid infinite loops. Consider using conditional expressions with `if: github.actor != 'automation-user'` to prevent recursive execution.
-
-**Option 2: Use a GitHub App**
-
-Create a GitHub App and use its authentication token instead of `GITHUB_TOKEN`. This is the recommended approach for organizations as it provides better security, auditability, and granular permissions:
-
-```yaml wrap
-# In your workflow frontmatter
-env:
-  GH_TOKEN: ${{ steps.generate-token.outputs.token }}
-
-steps:
-  - name: Generate token
-    id: generate-token
-    uses: actions/create-github-app-token@v1
-    with:
-      app-id: ${{ secrets.APP_ID }}
-      private-key: ${{ secrets.APP_PRIVATE_KEY }}
-```
-
-The GitHub App must have **Contents** (read and write) and **Pull requests** (read and write) permissions. PRs created with the app's token will trigger CI workflows and be attributed to the app.
-
-> [!TIP]
-> GitHub Apps provide better security than PATs because they have repository-scoped permissions, automatic token expiration, and don't require a user account. They're ideal for organization-wide automation.
-
-**Option 3: Use workflow_run trigger**
+**Option 2: Use workflow_run trigger**
 
 Configure your CI workflows to run on `workflow_run` events, which allows them to react to completed workflows:
 
@@ -354,10 +316,6 @@ on:
 
 This approach maintains security while allowing CI to run after PR creation. See [GitHub Actions workflow_run documentation](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) for details.
 
-**Recommendation:**
-
-For organizations, **Option 2 (GitHub App)** provides the best security and auditability. For individual users or smaller teams, **Option 1 (PAT with a service account)** is simpler to set up. In both cases, ensure proper safeguards are in place to prevent recursive workflow execution.
-
 ## Workflow Design
 
 ### Should I focus on one workflow, or write many different ones?

diff --git a/docs/src/content/docs/reference/frontmatter-full.md b/docs/src/content/docs/reference/frontmatter-full.md
@@ -127,55 +127,6 @@ on:
     events: []
       # Array items: GitHub Actions event name.
 
-  # DEPRECATED: Use 'slash_command' instead. Special command trigger for /command
-  # workflows (e.g., '/my-bot' in issue comments). Creates conditions to match slash
-  # commands automatically.
-  # (optional)
-  # This field supports multiple formats (oneOf):
-
-  # Option 1: Null command configuration - defaults to using the workflow filename
-  # (without .md extension) as the command name
-  command: null
-
-  # Option 2: Command name as a string (shorthand format, e.g., 'customname' for
-  # '/customname' triggers). Command names must not start with '/' as the slash is
-  # automatically added when matching commands.
-  command: "example-value"
-
-  # Option 3: Command configuration object with custom command name
-  command:
-    # Name of the slash command that triggers the workflow (e.g., '/deploy', '/test').
-    # Used for command-based workflow activation.
-    # (optional)
-    # This field supports multiple formats (oneOf):
-
-    # Option 1: Custom command name for slash commands (e.g., 'helper-bot' for
-    # '/helper-bot' triggers). Command names must not start with '/' as the slash is
-    # automatically added when matching commands. Defaults to workflow filename
-    # without .md extension if not specified.
-    name: "My Workflow"
-
-    # Option 2: Array of command names that trigger this workflow (e.g., ['cmd.add',
-    # 'cmd.remove'] for '/cmd.add' and '/cmd.remove' triggers). Each command name must
-    # not start with '/'.
-    name: []
-      # Array items: Command name without leading slash
-
-    # Events where the command should be active. Default is all comment-related events
-    # ('*'). Use GitHub Actions event names.
-    # (optional)
-    # This field supports multiple formats (oneOf):
-
-    # Option 1: Single event name or '*' for all events. Use GitHub Actions event
-    # names: 'issues', 'issue_comment', 'pull_request_comment', 'pull_request',
-    # 'pull_request_review_comment', 'discussion', 'discussion_comment'.
-    events: "*"
-
-    # Option 2: Array of event names where the command should be active (requires at
-    # least one). Use GitHub Actions event names.
-    events: []
-      # Array items: GitHub Actions event name.
-
   # Push event trigger that runs the workflow when code is pushed to the repository
   # (optional)
   # This field supports multiple formats (oneOf):
@@ -914,18 +865,9 @@ network:
 # (optional)
 # This field supports multiple formats (oneOf):
 
-# Option 1: Legacy string format for sandbox type: 'default' for no sandbox,
-# 'sandbox-runtime' or 'srt' for Anthropic Sandbox Runtime, 'awf' for Agent
-# Workflow Firewall
-sandbox: "default"
-
 # Option 2: Object format for full sandbox configuration with agent and mcp
 # options
 sandbox:
-  # Legacy sandbox type field (use agent instead)
-  # (optional)
-  type: "default"
-
   # Agent sandbox type: 'awf' uses AWF (Agent Workflow Firewall), 'srt' uses
   # Anthropic Sandbox Runtime, or false to disable agent sandbox. Defaults to 'awf'
   # if not specified. Note: Disabling the agent sandbox (false) removes firewall
@@ -949,10 +891,6 @@ sandbox:
     # (optional)
     id: "awf"
 
-    # Legacy: Sandbox type to use (use 'id' instead)
-    # (optional)
-    type: "awf"
-
     # Custom command to replace the default AWF or SRT installation. For AWF: 'docker
     # run my-custom-awf-image'. For SRT: 'docker run my-custom-srt-wrapper'
     # (optional)
@@ -1008,43 +946,6 @@ sandbox:
       # (optional)
       enableWeakerNestedSandbox: true
 
-  # Legacy custom Sandbox Runtime configuration (use agent.config instead). Note:
-  # Network configuration is controlled by the top-level 'network' field, not here.
-  # (optional)
-  config:
-    # Filesystem access control configuration for sandboxed workflows. Controls
-    # read/write permissions and path restrictions for file operations.
-    # (optional)
-    filesystem:
-      # Array of path patterns that deny read access in the sandboxed environment. Takes
-      # precedence over other read permissions.
-      # (optional)
-      denyRead: []
-        # Array of strings
-
-      # Array of path patterns that allow write access in the sandboxed environment.
-      # Paths outside these patterns are read-only.
-      # (optional)
-      allowWrite: []
-        # Array of strings
-
-      # Array of path patterns that deny write access in the sandboxed environment.
-      # Takes precedence over other write permissions.
-      # (optional)
-      denyWrite: []
-        # Array of strings
-
-    # When true, log sandbox violations without blocking execution. Useful for
-    # debugging and gradual enforcement of sandbox policies.
-    # (optional)
-    ignoreViolations:
-      {}
-
-    # When true, allows nested sandbox processes to run with relaxed restrictions.
-    # Required for certain containerized tools that spawn subprocesses.
-    # (optional)
-    enableWeakerNestedSandbox: true
-
   # MCP Gateway configuration for routing MCP server calls through a unified HTTP
   # gateway. Requires the 'mcp-gateway' feature flag to be enabled. Per MCP Gateway
   # Specification v1.0.0: Only container-based execution is supported.
@@ -1469,7 +1370,7 @@ tools:
     args: []
       # Array of strings
 
-  # GitHub Agentic Workflows MCP server for workflow introspection and analysis.
+  # GH-AW as an MCP server for workflow introspection and analysis.
   # Provides tools for checking status, compiling workflows, downloading logs, and
   # auditing runs.
   # (optional)
@@ -1906,40 +1807,6 @@ safe-outputs:
   # (optional)
   # This field supports multiple formats (oneOf):
 
-  # Option 1: DEPRECATED: Use 'create-agent-session' instead. Configuration for
-  # creating GitHub Copilot coding agent sessions from agentic workflow output using gh
-  # agent-task CLI. The main job does not need write permissions.
-  create-agent-task:
-    # Base branch for the agent session pull request. Defaults to the current branch
-    # or repository default branch.
-    # (optional)
-    base: "example-value"
-
-    # Maximum number of agent sessions to create (default: 1)
-    # (optional)
-    max: 1
-
-    # Target repository in format 'owner/repo' for cross-repository agent session
-    # creation. Takes precedence over trial target repo settings.
-    # (optional)
-    target-repo: "example-value"
-
-    # List of additional repositories in format 'owner/repo' that agent sessions can
-    # be created in. When specified, the agent can use a 'repo' field in the output to
-    # specify which repository to create the agent session in. The target repository
-    # (current or target-repo) is always implicitly allowed.
-    # (optional)
-    allowed-repos: []
-      # Array of strings
-
-    # GitHub token to use for this specific output type. Overrides global github-token
-    # if specified.
-    # (optional)
-    github-token: "${{ secrets.GITHUB_TOKEN }}"
-
-  # Option 2: Enable agent session creation with default configuration
-  create-agent-task: null
-
   # Enable creation of GitHub Copilot coding agent sessions from workflow output. Allows
   # workflows to start interactive agent conversations.
   # (optional)