Add mention-in-issue and mention-in-pr variants with sandbox disabled

[Copilot]

Some projects need Docker access during agent runs (for example in setup-commands), which is blocked by the default sandboxed mention workflows. This PR adds no-sandbox variants without replacing the existing sandboxed workflows.

What changed

• Added new workflow variants:
  • gh-aw-mention-in-issue-no-sandbox
  • gh-aw-mention-in-pr-no-sandbox
• Both variants set sandbox.agent: false, so the agent runs directly on the runner and can access Docker.
• Added consumer docs/examples for both variants under gh-agent-workflows/mention-in-issue-no-sandbox/ and gh-agent-workflows/mention-in-pr-no-sandbox/.
• Added compiled lock workflows in .github/workflows/ for both no-sandbox variants.
• Updated mkdocs.yml navigation to include both no-sandbox workflow docs.
• Updated scripts/dogfood.sh EXCLUDED_WORKFLOWS to exclude both no-sandbox variants and avoid duplicate /ai trigger conflicts in this repository.

Consumer usage

jobs:
  run:
    uses: elastic/ai-github-actions/.github/workflows/gh-aw-mention-in-issue-no-sandbox.lock.yml@v0
    secrets:
      COPILOT_GITHUB_TOKEN: $\{\{ secrets.COPILOT_GITHUB_TOKEN }}

Warning

Disabling the agent sandbox removes the sandbox firewall and filesystem isolation. Use these variants only when Docker access is required.

• Fixes Add mention-in-issue and mention-in-pr with sandbox: false #366

Generated by Update PR Body

[coderabbitai]

📝 Walkthrough

Walkthrough

This PR adds two new GitHub Actions workflow variants—"mention-in-issue-no-sandbox" and "mention-in-pr-no-sandbox"—that operate without sandbox restrictions, enabling direct Docker access. Includes generated lock files, workflow markdown definitions, documentation, example configurations, navigation updates, and script exclusions.

Changes

Cohort / File(s)	Summary
Workflow Definitions .github/workflows/gh-aw-mention-in-issue-no-sandbox.lock.yml, .github/workflows/gh-aw-mention-in-issue-no-sandbox.md, .github/workflows/gh-aw-mention-in-pr-no-sandbox.md	Added generated workflow lock file and markdown configuration files for issue and PR mention workflows without sandbox restrictions, defining agent orchestration, MCP tooling, security checks, and Copilot CLI integration.
Documentation & Examples gh-agent-workflows/mention-in-issue-no-sandbox/README.md, gh-agent-workflows/mention-in-issue-no-sandbox/example.yml, gh-agent-workflows/mention-in-pr-no-sandbox/README.md, gh-agent-workflows/mention-in-pr-no-sandbox/example.yml	Added README documentation describing workflow activation, inputs, safe outputs, and example workflow configurations for both issue and PR mention no-sandbox variants.
Configuration & Navigation mkdocs.yml, scripts/dogfood.sh	Updated MkDocs navigation to include two new workflow entries under Human-coordinated workflows, and added workflow names to dogfood exclusion list.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related PRs

• Add quick setup script for gh-aw workflows #173: Adds a quick-setup script that installs these new mention-in-issue and mention-in-pr no-sandbox workflows into repositories, providing automation for the workflow setup process.
• docs: split GitHub Agent workflows into human, event-driven, and scheduled #337: Modifies MkDocs navigation entries (mkdocs.yml) to organize and document GitHub Agent workflow variants, similar to workflow documentation structure changes.
• Clarify lock files and trigger files are auto-generated; add do-not-modify headers #335: Updates generated GitHub workflow artifacts and adds documentation headers for generated lock/trigger files, aligning with patterns for workflow file generation and modification tracking.

Suggested reviewers

• github-actions

Poem

🐰 Sandbox walls come tumbling down,
Docker runs in our workflow town,
Two new paths for agents free,
Issue and PR, wild as can be! ✨

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main change: adding two new workflow variants with sandbox disabled.
Linked Issues check	✅ Passed	The pull request successfully implements the requirements from issue #366: adds mention-in-issue and mention-in-pr workflow variants with sandbox disabled [#366], preserving existing sandboxed workflows, enabling Docker access for projects that need it.
Out of Scope Changes check	✅ Passed	All changes are properly scoped to adding no-sandbox workflow variants and their documentation; minor supporting changes to dogfood.sh exclusions and mkdocs navigation are directly related to the new workflows.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

• 📝 Generate docstrings (stacked PR)
• 📝 Generate docstrings (commit on current branch)

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch copilot/add-mention-in-issue-and-pr

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

🧹 Nitpick comments (1)

.github/workflows/gh-aw-mention-in-pr-no-sandbox.md (1)

93-97: Note: eval usage with dynamic setup commands.

Using eval with the SETUP_COMMANDS input is a common CI/CD pattern for flexible setup but carries inherent risk. The risk is mitigated here by:

• Workflow trigger restricted to admin/maintainer/write roles
• setup-commands is a workflow input, not arbitrary user input
• Pattern is standard for dynamic CI setup

This is acceptable in context but worth noting for security awareness.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/gh-aw-mention-in-pr-no-sandbox.md around lines 93 - 97,
The workflow uses eval "$SETUP_COMMANDS" (env SETUP_COMMANDS) which can be
dangerous; replace the eval usage in the "Repo-specific setup" step by
validating or sanitizing SETUP_COMMANDS and executing it via a safer mechanism
(e.g., run with bash -lc or a controlled wrapper) and/or implement a whitelist
or explicit parsing of allowed subcommands before executing; update the step
that references SETUP_COMMANDS and the run: eval "$SETUP_COMMANDS" invocation to
call the safer executor and add input validation logic to mitigate injection
risk.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In @.github/workflows/gh-aw-mention-in-pr-no-sandbox.md:
- Around line 93-97: The workflow uses eval "$SETUP_COMMANDS" (env
SETUP_COMMANDS) which can be dangerous; replace the eval usage in the
"Repo-specific setup" step by validating or sanitizing SETUP_COMMANDS and
executing it via a safer mechanism (e.g., run with bash -lc or a controlled
wrapper) and/or implement a whitelist or explicit parsing of allowed subcommands
before executing; update the step that references SETUP_COMMANDS and the run:
eval "$SETUP_COMMANDS" invocation to call the safer executor and add input
validation logic to mitigate injection risk.