setup-copilot-devcontainer

Files (7)

• SKILL.md
• env-block.example · templates/
• install-block.sh · templates/
• network-manifest-entries.json · templates/
• post-start-block.sh · templates/
• readme-bullet.md · templates/
• yolo-alias-block.sh · templates/

SKILL.md (first lines)

# Setup Copilot Devcontainer

Adds GitHub Copilot CLI to a devcontainer already generated by the
[setup-devcontainer](../setup-devcontainer/SKILL.md) skill. This skill never
touches `devcontainer.json` or the `Dockerfile` — it appends its own
marker-keyed content to `post-create.sh`, `post-start.sh` (if skill sync is
opted into), `.env.example`, and `README.md`, and idempotently ensures its own
Network Manifest entry exists in `.devcontainer/network-manifest.json`.

## 0. Security & Trust

This skill's generated automation touches three areas an external audit may flag. Each is
opt-in, scoped to this container, and exists for a specific reason — none of it runs on the
host, only inside the generated devcontainer.

- **Installer Provenance**: installs Copilot CLI via GitHub's own official install script
  (`https://gh.io/copilot-install`, GitHub's own short link for it). Runs once, at container
  creation (`postCreateCommand`), not on every start — and only if `~/.local/bin/copilot`
  doesn't already exist.
- **Agent Authority**: `copilot-yolo` is **not** a persistent auto-approve alias — it's a
  manual-invocation reminder that prints Copilot's current `--allow-all`/`--autopilot` flags
  and GitHub's own caveat against aliasing them for every session start, rather than running
  anything unattended itself. Off by default; only added if the guidance was accepted during
  setup.
- **Skill Source Trust**: if skill sync is accepted, the source(s) you name are re-synced into
  the Shared Skills Directory (`~/.agents/skills`) on every container start — the same shared
  directory Codex's and Antigravity's skill-sync also write into. Nothing is wiped — a skill
  removed upstream stays until deleted by hand. The real trust decision is the source itself:
  naming one means trusting its skills unattended, with no per-skill review step, every time
  the container starts. Off by default.

See [ADR-0007](../setup-devcontainer/docs/adr/0007-agent-trust-hub-audit-response.md) for the
full reasoning and the alternatives rejected.

## 1. Detect the base devcontainer

```bash
test -f .devcontainer/devcontainer.json && test -f .devcontainer/post-create.sh && echo ok
```

If either file is missing, **refuse** — tell the user to run
`setup-devcontainer` first, and stop. Do not generate or patch anything.

## 2. Ask this tool's options

- **YOLO alias**: add `copilot-yolo`? This is a manual-invocation reminder
  describing Copilot's current `--allow-all`/`--autopilot` flags, **not** a
  persistent auto-approve alias — GitHub's own docs explicitly warn against
  ever aliasing these flags for every session start.
- **Automatic skill sync**: sync AI-agent skills into the Shared Skills
  Directory (`~/.agents/skills`) automatically on every container start?
  Same mechanism as the other CLI skills — two ready-made suites
  (`mattpocock/skills`, `ken-guru/skills`) plus any individually named
  skill, validated live via `npx -y skills add <source> --list` before
  rendering anything.

## 3. Patch `post-create.sh`

Append [templates/install-block.sh](templates/install-block.sh) verbatim —
this includes both the CLI install and the `COPILOT_AUTO_UPDATE=false`
shell-profile export, both mandatory (not opted into):

```bash
scripts/patch-if-absent.sh append .devcontainer/post-create.sh "# --- Copilot ---" templates/install-block.sh
```

If YOLO alias guidance was accepted, also append
[templates/yolo-alias-block.sh](templates/yolo-alias-block.sh), under its
own independent marker:

```bash
scripts/patch-if-absent.sh append .devcontainer/post-create.sh "# --- Copilot yolo-alias ---" templates/yolo-alias-block.sh
```

## 4. Patch the Network Manifest — unconditional, every run

Ensure Copilot CLI's own `.copilot.networkAllowlist` entry exists in
`.devcontainer/network-manifest.json`, regardless of any answer above — this
is what lets an opted-in network firewall (a separate, base-owned layer)
allow the hosts Copilot itself needs. `github.com` and `api.github.com` are
already covered by the manifest's seeded `baseline` entry, so Copilot's own
entry doesn't repeat them:

```bash
scripts/patch-json-array-if-absent.sh .devcontainer/network-manifest.json .copilot.networkAllowlist templates/network-manifest-entries.json
```

## 5. Patch `post-start.sh` (only if skill sync was accepted)

Render [templates/post-start-block.sh](templates/post-start-block.sh) with
`{{SKILLS_SOURCES_COMMANDS}}` substituted to one `npx -y skills add <source>
--skill '*' -a github-copilot -y --copy -g` line per whole-suite source (or
`--skill '<name>'` per individual pick), then append it:

```bash
scripts/patch-if-absent.sh append .devcontainer/post-start.sh "# --- Copilot skill-sync ---" <rendered-block>
```

## 6. Patch `.env.example` — unconditional, every run

Append [templates/env-block.example](templates/env-block.example), Copilot's
own token block. Its `COPILOT_GITHUB_TOKEN` line stays **commented out**: an
uncommented placeholder would be exported as a real value and override the
`GH_TOKEN` fallback. `.env.example` is the only env file this skill writes;
`.devcontainer/.env` holds the user's live tokens.

```bash
scripts/patch-if-absent.sh append .devcontainer/.env.example "# --- Copilot token ---" templates/env-block.example
```

## 7. Patch `README.md`

```bash
scripts/patch-if-absent.sh append .devcontainer/README.md "- Copilot" templates/readme-bullet.md
```

## 8. Verify

Re-run every `patch-if-absent.sh`/`patch-json-array-if-absent.sh` command

From ken-guru/skills, MIT.

More from ken-guru/skills