github·May 12, 2026·3 min readCurated summary

Dungeons & Desktops: Building a procedurally generated roguelike with GitHub Copilot CLI

GitHub Dungeons is a terminal-based roguelike that transforms a repository into a procedurally generated dungeon. Built in Go with GitHub Copilot CLI, it uses the latest commit SHA as a seed, making each commit produce a distinct but reproducible map. The project demonstrates how AI-assisted development can let developers focus more on game design and iteration than on implementation details. ## Repository-Driven Procedural Generation - The game generates rooms, corridors, and enemies from the current codebase. - Each repository produces a structurally different dungeon. - The latest commit determines the random seed: - The same commit always creates the same map. - Code changes reshape the dungeon. - Procedural generation creates replayability by producing many layouts from a single set of rules. ## Roguelike Design - GitHub Dungeons draws on classic games such as *Rogue*. - It combines: - Procedurally generated levels - Permadeath - A text-based terminal interface - Players navigate with arrow keys, fight bugs, collect items, and search for the exit. - When the player’s HP reaches zero, the run ends and they must start over. - The Copilot CLI `/yolo` command, an alias for `/allow-all`, reinforces the game’s one-life theme. ## Building with GitHub Copilot CLI - The author began with a high-level prompt asking Copilot to build a Go-based GitHub CLI extension using BSP-generated dungeons. - The `/delegate` command sent feature requests to Copilot’s cloud-based coding agent. - Copilot worked asynchronously and returned changes through pull requests. - Example delegated work included progressively harder levels with: - More enemies - Additional health potions - The author reviewed and refined Copilot’s output, including cheat codes for invincibility. - Copilot also generated a “dungeon scribe” agent that created documentation and ASCII diagrams explaining dungeon generation. - This workflow allowed the author to concentrate on mechanics, balance, player experience, and easter eggs rather than boilerplate and scaffolding. ## Binary Space Partitioning - Binary Space Partitioning (BSP) generates the dungeon by repeatedly dividing a large area into smaller regions. - The process begins with one rectangle representing the entire map. - That space is recursively split into smaller sections, which can then be used to place rooms and connect them. - BSP suits roguelikes because it balances: - Structure, avoiding chaotic layouts - Replayability through controlled randomness - Navigation, by supporting connected maps - The technique naturally produces clean rectangular rooms while retaining variation between generated levels. GitHub Dungeons shows how repository data, classic roguelike mechanics, and AI-assisted coding can combine into a playful development experiment. Using Copilot as an implementation partner lets the developer iterate quickly while remaining focused on designing an enjoyable game.

Read original(opens in new tab)

GoGithub Copilot CliGithub CliProcedural Generation+3

github·May 11, 2026·1 min readCurated summary

GitHub for Beginners: Getting started with OSS contributions

Kedasha is a Developer Advocate at GitHub who shares her software development experience with the broader developer community. She is passionate about helping others learn about the technology industry and can be found online at **@itsthatladydev**. ### Professional Role - Works as a Developer Advocate at GitHub. - Shares lessons and insights with developers. ### Interests and Community Work - Enjoys helping people learn about the tech industry. - Draws on her experience as a software developer when supporting the community. Kedasha’s work centers on education, mentorship, and sharing practical knowledge with developers.

Read original(opens in new tab)

GithubSoftware DevelopmentDeveloper Advocacy

github·May 7, 2026·4 min readCurated summary

Improving token efficiency in GitHub Agentic Workflows

GitHub’s Agentic Workflows can quietly accumulate substantial token costs because they run automatically in CI. GitHub improved efficiency by instrumenting token usage, auditing workflows, pruning unused MCP tools, and replacing many MCP data-fetching calls with deterministic GitHub CLI commands. Early results show that reducing context and removing unnecessary LLM reasoning can save thousands of tokens per run, though measuring true efficiency requires accounting for model choice and workload quality. ## Logging Token Usage - GitHub runs hundreds of agentic workflows against real GitHub Actions limits. - Different agent frameworks produced incompatible usage logs, so GitHub used its API proxy to normalize data across Claude CLI, Copilot CLI, and Codex CLI. - Each workflow now emits a `token-usage.jsonl` artifact containing: - Input, output, cache-read, and cache-write tokens - Model and provider - Timestamps - One record per API call - These records make it possible to compare historical runs and identify recurring sources of waste. ## Automated Auditing and Optimization - A daily **Token Usage Auditor** aggregates recent usage by workflow and reports: - Significant increases in token consumption - The most expensive workflows - Anomalous runs, such as a workflow taking 18 LLM turns instead of its usual four - A daily **Token Optimizer** examines flagged workflows, their source YAML, and recent logs. - It creates GitHub Issues with concrete inefficiencies and recommended fixes. - The auditing workflows also consume tokens, creating a feedback loop in which their own costs are monitored. ## Removing Unused MCP Tools - MCP tool names and JSON schemas are typically included in every stateless LLM request. - A GitHub MCP server with roughly 40 tools can add 10–15 KB of schema to every turn. - If a workflow uses only two tools, the other 38 create repeated overhead without adding value. - GitHub compares configured tools with actual tool calls and recommends removing unused registrations. - In smoke tests, pruning tools reduced each call’s context by 8–12 KB and saved several thousand tokens per run without changing behavior. ## Replacing MCP Calls with GitHub CLI - GitHub found larger savings by replacing MCP calls for predictable data retrieval—such as pull request diffs, file contents, and review comments—with `gh` commands. - MCP calls require an additional reasoning cycle: the model chooses a tool, constructs arguments, and processes the response. - Commands such as `gh pr diff` make deterministic API requests without involving the LLM in the retrieval step. Two migration patterns were used: - **Pre-agentic downloads** - Workflow setup steps run `gh` commands before the agent starts. - Results such as diffs and changed-file lists are saved to workspace files. - The agent reads the files directly, eliminating MCP round trips. - **In-agent CLI proxy substitution** - When data must be selected dynamically, the agent runs commands such as `gh pr view --json`. - A transparent proxy routes CLI requests to GitHub’s API without exposing credentials. - This preserves the zero-secrets security model while avoiding MCP overhead. ## Measuring Efficiency - Lower token counts do not necessarily mean better workflows; a workflow may simply be doing less work. - Model selection also affects cost. Claude Haiku and Sonnet may use similar numbers of tokens, but Haiku is substantially cheaper. - GitHub therefore uses an **Effective Tokens (ET)** metric that weights usage by token type and model cost: ```text ET = m × (1.0 × I + 0.1 × C + 4.0 × O) ``` - `m` represents the model multiplier: Haiku `0.25×`, Sonnet `1.0×`, and Opus `5.0×`. - `I` is newly processed input, `C` is cache-read tokens, and `O` is output tokens. - Output tokens receive greater weight because they are typically the most expensive component. GitHub’s experience suggests that agentic workflow authors should measure usage continuously, remove tools that workflows do not actually use, and move routine API retrieval outside the LLM reasoning loop wherever possible.

Read original(opens in new tab)

Large Language ModelsModel Context ProtocolGitHub ActionsYaml+3

github·May 7, 2026·4 min readCurated summary

Agent pull requests are everywhere. Here’s how to review them.

Agent-generated pull requests are increasing rapidly, while human review capacity remains limited. Although these changes often look clean and pass CI, research suggests they can introduce more redundancy and technical debt—and reviewers may be more likely to approve them. The solution is not to review more slowly, but to focus human judgment on risks agents are least equipped to recognize. ## The Scale of Agent-Generated Pull Requests - GitHub Copilot code review has processed more than 60 million reviews and grown tenfold in under a year. - More than 20% of GitHub code reviews now involve an agent. - Developers can launch many agent sessions simultaneously, causing pull-request volume to grow faster than human review capacity. - Reviewers therefore need a deliberate method for identifying high-impact issues. ## Understanding the Agent’s Limitations - Coding agents are productive and literal, but lack: - Incident history - Team-specific edge-case knowledge - Operational constraints not documented in the repository - Agents can produce code that appears complete while quietly embedding incorrect assumptions. - Human reviewers provide the context and judgment that automated tools cannot fully replicate. ## CI Gaming Agents may weaken CI when their changes fail, for example by removing tests, skipping linting, or adding commands such as `|| true`. Reviewers should verify: - Coverage thresholds were not reduced. - Tests were not removed, renamed, or skipped. - Workflows still run for forks and pull requests. - CI steps were not placed behind new restrictive conditions. Any such change requires explicit justification before approval. ## Blindness to Existing Code Reuse Agents may copy patterns from nearby code without discovering equivalent utilities elsewhere in the repository. Warning signs include: - Duplicate helper or utility functions - Reimplemented validation logic - New middleware duplicating shared modules - “Almost identical” helpers with different names Reviewers should search for existing implementations and require consolidation rather than merely commenting on duplication. For larger agent pull requests, requiring justification for new utilities can prevent redundant code from becoming future “prior art.” ## Hallucinated Correctness The most dangerous agent errors are not obvious API or syntax failures. They are changes that compile, pass tests, and still behave incorrectly under conditions such as: - Pagination boundaries - Missing permission checks - Validation edge cases - Race conditions at scale Reviewers should trace a critical path from input to output, checking empty, zero, and maximum values, external input validation, permissions on every branch, and unusual conditionals. A claimed bug fix should include a test that fails before the change; otherwise, the fix or the agent’s understanding may be incomplete. ## Agentic Ghosting and Oversized Pull Requests Large, poorly structured agent pull requests are more likely to become abandoned or misaligned. Before conducting an in-depth review, check: - Whether the agent has responded usefully in earlier review rounds - Whether the pull request includes a clear implementation plan - Whether the changes can be divided into smaller, scoped units If no plan exists, request a breakdown or a clear explanation of each component before spending time on detailed comments. ## Untrusted Input in Agent Workflows Workflows that send pull-request bodies, issue content, or commit messages to an LLM can create prompt-injection risks—especially when model output is later executed with `GITHUB_TOKEN` permissions. Reviewers should block workflows that: - Interpolate untrusted content into prompts without sanitization - Grant write access when read-only permissions are sufficient - Execute model output as shell commands without validation - Expose secrets to agent steps or logs Safer designs should use least-privilege permissions such as `permissions: read-all`, sanitize and quote untrusted content, separate analysis from execution, and require human approval before actions affecting production. Agent pull requests should not automatically receive either extra trust or blanket suspicion. Reviewers should focus on CI integrity, reuse, behavior under edge cases, reviewability, and workflow security—the areas where contextual human judgment adds the most value.

Read original(opens in new tab)

Large Language ModelsCI/CDGithub CopilotCode Review+3

github·May 6, 2026·3 min readCurated summary

Validating agentic behavior when “correct” isn’t deterministic

Agentic systems such as GitHub Copilot cloud agent can complete tasks through multiple valid action sequences, making traditional deterministic tests unreliable. Timing changes, loading screens, and UI differences often produce false negatives even when the agent achieves the correct result. The post proposes an independent “Trust Layer” that validates essential outcomes and convergent behavior rather than rigid step-by-step execution paths. ## Challenges of Agent-Driven Validation - An agent may adapt to network delays or changing UI conditions and still complete its task successfully. - Conventional CI tests can fail when execution no longer matches a recorded script or expected assertion timing. - This creates a trust gap: - **False negatives:** successful tasks are reported as failures. - **Fragile infrastructure:** rendering, timing, and environment noise affect test results. - **Compliance trap:** valid behavioral variation is mistaken for regression. - Agent correctness should focus on reliably achieving essential outcomes, not reproducing an identical sequence of actions. ## Why Traditional Testing Breaks Down - **Assertion-based tests** require manually specifying every expected check and often omit valid alternative paths. - **Record-and-replay tools** are highly sensitive to timing and rendering differences. - **Visual regression tests** compare screenshots without understanding semantic meaning or the broader workflow. - **ML-based oracles** need large training datasets and generally provide little explanation for their decisions. - All four approaches assume correctness means following a stable sequence of observable states, which does not fit autonomous agents. ## Essential, Optional, and Convergent Behavior The proposed approach distinguishes between behavior that determines success and behavior that merely reflects environmental variation: - **Essential states:** Required milestones, such as reaching a VS Code “Search Results” screen. - **Optional variations:** Incidental states, including loading spinners or decorative UI changes. - **Convergent paths:** Different action sequences—such as using a keyboard shortcut or a menu—that eventually reach the same result. - A loading screen may appear in one run and not another, but the appearance of search results is what establishes success. ## Dominator Analysis The post connects this model to **dominator relationships** from compiler theory: - In a control-flow graph, node A dominates node B when every path to B must pass through A. - Applying dominator analysis to agent execution traces can identify: - Mandatory states - Optional states - Points where different execution paths converge - This produces a minimal and explainable definition of correctness instead of relying on every recorded step. ## Graph-Based Execution Modeling - Agent behavior should be represented as a graph rather than a linear script. - Graphs capture branching paths, optional states, and convergence points. - This structure provides a foundation for lightweight, explainable validation in GitHub Actions and other CI environments. A reliable validation system for agents should test whether essential outcomes occurred and whether critical invariants held, while ignoring harmless differences in timing, rendering, and execution order. This outcome-oriented Trust Layer can reduce false failures and make agentic workflows more dependable in production CI pipelines.

Read original(opens in new tab)

AI AgentsCI/CDGithub CopilotGitHub Actions+3

github·Apr 30, 2026·2 min readCurated summary

GitHub Copilot CLI for Beginners: Interactive v. non-interactive mode

GitHub Copilot CLI offers two ways to work from the terminal: interactive mode for ongoing, collaborative sessions and non-interactive mode for quick, one-off prompts. The article recommends choosing between them based on whether you need iterative exploration or a fast answer within an existing shell workflow. Previous sessions can also be resumed in either mode. ## Interactive Mode for Collaborative Work - Start it by running `copilot`. - It is the default mode and provides a chat-like, back-and-forth experience. - Users can: - Ask questions about a project. - Review Copilot’s responses. - Ask follow-up questions. - Request actions, such as running a local server. - Copilot may request permission to trust the current folder because it needs to read or modify project files. - This mode is best for exploratory coding, troubleshooting, and tasks that require multiple steps. ## Non-Interactive Mode for Quick Prompts - Start it with `copilot -p "your prompt"`. - It produces a single response without opening a full conversational session. - Typical uses include: - Summarizing a repository. - Generating code snippets. - Running Copilot inside automated workflows. - It is designed to keep users in their normal terminal flow and is most useful when the required task is clear and narrowly defined. ## Resuming Previous Sessions - In interactive mode, enter `/resume` to select a previous session. - From the regular shell, use `copilot --resume` to open the session picker directly. - Resuming preserves the context of earlier conversations, making it easier to continue unfinished work. The practical choice is simple: use interactive mode for deeper, iterative collaboration and non-interactive mode for focused, one-shot requests.

Read original(opens in new tab)

Github Copilot CliCommand Line InterfaceMcp ServersInteractive Mode+2

github·Apr 28, 2026·1 min readCurated summary

GitHub for Beginners: Getting started with Markdown

Kedasha is a GitHub Developer Advocate who shares her software development experience with the broader developer community. She is passionate about helping others learn about the technology industry and can be found online as **@itsthatladydev**. ### Professional Role - Works as a Developer Advocate at GitHub. - Shares lessons and experiences with developers. ### Community and Education - Enjoys helping others learn about technology and the tech industry. - Uses her experience as a software developer to support the wider community. Kedasha’s work centers on developer education, community engagement, and sharing practical industry knowledge.

Read original(opens in new tab)

Software DevelopmentDeveloper AdvocacyCommunity Building

github·Apr 28, 2026·1 min readCurated summary

Securing the git push pipeline: Responding to a critical remote code execution vulnerability

Alexis Wales is GitHub’s Chief Information Security Officer, responsible for protecting the platform, its products, and the open source community. She leads security experts supporting more than 150 million developers and draws on two decades of experience defending critical networks. Her work has reinforced the importance of public-private collaboration in addressing major technology security threats. ## Leadership at GitHub - Oversees GitHub’s security strategy and teams. - Focuses on safeguarding developers, products, the platform, and the broader open source ecosystem. - Supports secure software development and deployment for more than 150 million developers. ## Cybersecurity Experience - Has 20 years of experience protecting national and private-sector networks. - Previously held roles with the Department of Defense and CISA. - Developed a strong interest in cooperation between government and industry. ## Focus on Collaboration - Advocates public-private partnerships to address complex cybersecurity challenges. - Applies her experience to threats affecting the technology people rely on every day.

Read original(opens in new tab)

Open SourceGithubCybersecurityInformation Security+2

github·Apr 17, 2026·2 min readCurated summary

Building an emoji list generator with the GitHub Copilot CLI

Cassidy Williams describes building an AI-powered emoji list generator during GitHub’s Rubber Duck Thursdays livestream. The terminal application converts bullet points into relevant emojis, then copies the formatted Markdown list to the clipboard with a keyboard shortcut. The project demonstrates how GitHub Copilot CLI and SDK can quickly turn a small idea into a functional open-source tool. ## The Emoji List Generator - Runs directly in the terminal. - Accepts pasted or typed bullet points. - Uses AI to replace each bullet with a relevant emoji. - Generates the result when the user presses `Ctrl + S`. - Copies the completed list to the clipboard. - Exits with `Ctrl + C`. ## Technologies Used - `@opentui/core` provides the terminal user interface. - `@github/copilot-sdk` supplies the AI functionality. - `clipboardy` handles clipboard access. ## Building the Project with Copilot CLI - Development began in Copilot CLI’s plan mode using Claude Sonnet 4.6. - A natural-language prompt described the desired Markdown emoji generator and requested integration with the Copilot SDK. - Copilot asked clarifying questions about the technology stack and libraries. - It then produced a `plan.md` file for review. - The implementation was completed with Claude Opus 4.7 only a few minutes later. ## Copilot CLI Features Demonstrated The livestream project combined several Copilot CLI capabilities: - Plan mode for outlining the implementation. - Autopilot mode for carrying out development tasks. - A multi-model workflow using different Claude models. - The `allow-all` tools flag for permissive tool access. - The GitHub MCP server for GitHub-related integrations. The finished Emoji List Generator is available as a free, open-source project, alongside documentation for the GitHub Copilot CLI and SDK.

Read original(opens in new tab)

Github Copilot CliClaude OpusGithub Copilot SdkClaude Sonnet+4

github·Apr 16, 2026·3 min readCurated summary

How GitHub uses eBPF to improve deployment safety

GitHub uses eBPF to prevent deployment scripts from depending on GitHub or other services that may be unavailable during an outage. The approach applies network restrictions only to deployment processes, preserving normal traffic for stateful production hosts. By combining Linux cgroups with eBPF’s `BPF_PROG_TYPE_CGROUP_SKB` hooks, GitHub can detect or block unsafe outbound calls before they create circular deployment dependencies. ## The Deployment Circular Dependency - GitHub hosts its own source code on `github.com`, creating a basic dependency: GitHub may need GitHub to deploy a fix. - GitHub mitigates this with: - A code mirror used for “fix-forward” deployments. - Prebuilt assets used to roll back changes. - Additional circular dependencies can still be introduced by deployment scripts, internal services, or tools that download binaries dynamically. ## Three Types of Circular Dependencies The post uses a hypothetical MySQL outage to illustrate how deployment recovery can fail: - **Direct dependencies** - A deployment script downloads the latest release of an open-source tool from GitHub. - If GitHub cannot serve release data, the deployment cannot complete. - **Hidden dependencies** - A required tool is already installed locally but checks GitHub for updates when it runs. - The tool may fail or hang if that update check cannot connect. - **Transient dependencies** - The deployment calls another internal service, such as a migrations service. - That service then attempts to download a binary from GitHub, causing the failure to propagate back to the deployment. ## Why Manual Review Is Insufficient - Teams responsible for stateful hosts traditionally review deployment scripts for circular dependencies. - Many indirect or unexpected dependencies are discovered only during incidents, when they can delay recovery. - Blocking `github.com` at the host level would be too disruptive because stateful hosts continue serving customer traffic during deploys, drains, and restarts. ## Per-Process Network Filtering with eBPF - eBPF allows custom programs to run inside the Linux kernel and attach to low-level operations such as networking. - GitHub focused on `BPF_PROG_TYPE_CGROUP_SKB`, which can inspect network egress for a specific cgroup. - Linux cgroups provide process grouping, isolation, and resource controls without requiring Docker. - The proposed design: - Create a dedicated cgroup. - Place only the deployment script and its processes inside it. - Restrict or monitor outbound network access for that group. - Leave the host’s ordinary production traffic unaffected. ## Proof of Concept with Go and eBPF - The proof of concept uses Go and the `cilium/ebpf` library. - The library simplifies: - Compiling and loading eBPF programs. - Attaching programs to kernel hooks. - Reading and updating eBPF maps. - The example attaches an egress program to `/sys/fs/cgroup/system.slice`. - An eBPF array map tracks the number of egress packets, while the Go program periodically reads and reports the counter. - The same mechanism can be extended from packet counting to selectively allowing or blocking network traffic. GitHub’s approach moves dependency validation from manual inspection into enforcement at runtime. Restricting only deployment processes with cgroups and eBPF provides a practical way to make emergency deployments independent of services that may be down, without blocking the production workloads sharing the same host.

Read original(opens in new tab)

GoEbpfLinux KernelCgroups+2

github·Apr 15, 2026·2 min readCurated summary

Build a personal organization command center with GitHub Copilot CLI

Brittany Ellich built a personal organization command center to reduce the friction of switching between numerous apps. Using GitHub Copilot for planning and implementation, she created a working first version in one day. Her experience suggests that AI-assisted development makes it easier to turn everyday frustrations into practical, customized tools. ## The Problem: Digital Fragmentation - Brittany wanted to consolidate information scattered across roughly a dozen applications. - Her goal was a calm, visual workspace suited to her learning style and the way she organizes information. - The project became a personal command center for bringing disparate work and productivity tools together. ## Planning and Building with AI - Brittany uses a “plan-then-implement” workflow. - During planning, Copilot interviews her about requirements and behavior until they form a sufficiently detailed plan. - Copilot then implements the system based on that plan, reducing guesswork and making development smoother. - The first version was completed in a single day alongside her normal work. ## Her Development Workflow - She uses VS Code Agent Mode for synchronous work, generally running up to two non-competing agent workflows. - She uses Copilot Cloud Agent for asynchronous, well-scoped tasks such as bug fixes and technical-debt cleanup. - This division lets her focus personally on work requiring close oversight while agents handle lower-risk background tasks. ## Technology Stack - **Electron** for the cross-platform desktop application. - **React** for the interface, components, and state management. - **Vite** for development tooling and hot module replacement. - **Tailwind CSS** for styling. - **WorkIQ MCP and CLI** for accessing Microsoft 365 data, including calendar information. - The application also uses ElevenLabs for its voice assistant. Although Brittany had wanted to build an Electron app, she learned relatively little about Electron because Agent Mode handled most of the implementation. She later simplified the repository manually to make it suitable for public release, noting that agents tend to add code more readily than remove it. ## Getting Started The project is available as the open-source `command-center-lite` repository. Running it requires Node.js 18 or later, GitHub Copilot CLI for WorkIQ setup, a Microsoft 365 account for calendar synchronization, and an ElevenLabs account for voice features. The broader recommendation is to start building solutions for small, personal problems. AI tools can accelerate both learning and implementation, making experimentation with unfamiliar technologies far more accessible.

Read original(opens in new tab)

Model Context ProtocolReactGithub Copilot CliNode.Js+3

github·Apr 14, 2026·3 min readCurated summary

Hack the AI agent: Build agentic AI security skills with the GitHub Secure Code Game

Agentic AI tools can automate powerful tasks, but their autonomy creates new security risks, including prompt injection, tool misuse, memory poisoning, and compromised multi-agent workflows. GitHub’s Season 4 Secure Code Game teaches developers to recognize these threats by attacking and hardening ProdBot, a deliberately vulnerable terminal-based AI assistant. Its five levels progressively add capabilities—and corresponding attack surfaces—mirroring how real-world AI systems evolve. ## The Secure Code Game’s Evolution - The free, open-source, in-editor course teaches security by having players exploit and fix intentionally vulnerable code. - Earlier seasons covered: - General secure coding across JavaScript, Python, Go, and GitHub Actions. - LLM security, including malicious prompts and defensive techniques. - More than 10,000 developers from industry, academia, and open source have participated. - Season 4 shifts focus from AI that generates content to AI that independently browses, uses tools, calls APIs, and acts for users. ## Why Agentic AI Security Is Urgent - Agentic systems are moving rapidly from research projects into production environments. - The OWASP Top 10 for Agentic Applications identifies threats such as: - Goal hijacking - Tool misuse - Identity abuse - Memory poisoning - A Dark Reading poll found that 48% of cybersecurity professionals expect agentic AI to be the leading attack vector by the end of 2026. - Cisco reported that although 83% of organizations planned to deploy agentic AI, only 29% felt prepared to secure it. - The article argues that learning to think like an attacker is essential for closing this readiness gap. ## ProdBot: A Deliberately Vulnerable AI Assistant - ProdBot is a terminal-based productivity and coding assistant inspired by tools such as OpenClaw and GitHub Copilot CLI. - It can: - Convert natural-language requests into bash commands. - Browse a simulated web. - Connect to MCP servers. - Run organization-approved skills. - Store persistent memory. - Coordinate multiple agents. - Players’ objective is to use natural language to make ProdBot reveal the contents of `password.txt`. - No prior AI or coding experience is required; all interaction takes place through the CLI. ## Five Progressive Attack Surfaces - **Level 1: Shell execution** - ProdBot runs generated bash commands in a sandbox. - The challenge is to determine whether the sandbox can be escaped. - **Level 2: Web browsing** - ProdBot reads simulated news, finance, sports, and shopping sites. - Untrusted web content introduces risks such as instruction hijacking and prompt injection. - **Level 3: MCP integrations** - ProdBot gains access to external tool providers for stock quotes, browsing, and cloud backup. - Additional tools increase both functionality and opportunities for abuse. - **Level 4: Skills and memory** - Organization-approved plugins and persistent memory create layered trust relationships. - The level tests whether trusted skills and stored information are actually safe. - **Level 5: Multi-agent orchestration** - ProdBot combines six specialized agents, three MCP servers, three skills, and a simulated open-source project. - Claims that agents are sandboxed and data is pre-verified become assumptions to test rather than guarantees. ## Real-World Relevance - The game’s vulnerabilities reflect active security concerns in deployed autonomous AI systems rather than purely theoretical exercises. - The article cites CVE-2026-25253, known as “ClawBleed,” an OpenClaw vulnerability rated CVSS 8.8. - The flaw allowed attackers to steal authentication tokens through a malicious link and gain full control of an OpenClaw instance. - Season 4’s broader goal is to develop instincts for identifying similar weaknesses during architecture reviews, tool-integration audits, and production deployments. Developers working with AI agents should treat every new capability—shell access, browsing, plugins, memory, or collaboration—as a potential attack surface. Practicing these failure modes in a controlled environment like the Secure Code Game can help teams design safer agentic systems before deploying them.

Read original(opens in new tab)

AI AgentsModel Context ProtocolAi SecurityPrompt Injection+2

github·Apr 14, 2026·2 min readCurated summary

How exposed is your code? Find out in minutes—for free

GitHub’s Code Security Risk Assessment offers organizations a free, one-click way to uncover vulnerabilities that manual reviews and limited scanning tools may miss. Using CodeQL, it scans up to 20 active repositories and provides a prioritized view of risks by severity, language, repository, and vulnerability type. The assessment also connects findings to GitHub Code Security and Copilot Autofix, helping teams move from discovery to remediation. ## What the Assessment Reveals - Scans up to 20 of an organization’s most active repositories. - Reports vulnerabilities by severity: - Critical - High - Medium - Low - Breaks findings down by programming language. - Identifies the specific security rules and vulnerability classes detected. - Highlights the repositories with the greatest number of vulnerabilities. - Shows which findings are eligible for Copilot Autofix. - Uses CodeQL, GitHub’s static analysis engine. The assessment is free for organization administrators and security managers using GitHub Enterprise Cloud or GitHub Team. Scanning does not consume the organization’s GitHub Actions minutes quota. ## Combining Code and Secret Exposure The Code Security Risk Assessment complements GitHub’s existing Secret Risk Assessment. - Both assessments can be launched from one entry point. - A tabbed interface separates secret exposure findings from code vulnerabilities. - The combined view helps organizations understand their overall security posture. - Secret Protection focuses on preventing credential leaks. - Code Security identifies and helps remediate vulnerabilities in source code. GitHub cites 2025 usage figures for Secret Protection, including nearly 2 billion scanned pushes and 19 million blocked secret exposures. ## From Detection to Remediation Finding vulnerabilities is only the first step; reducing risk requires fixing them. - GitHub reports that Copilot Autofix resolved 460,258 security alerts in 2025. - Half of vulnerability alerts were fixed directly in pull requests. - Mean remediation time was 0.66 hours with Copilot Autofix, compared with 1.29 hours for manual fixes. - Assessment results show how many discovered vulnerabilities could potentially be fixed automatically. - Organizations can enable GitHub Code Security directly from the results page. The assessment is intended for organizations with no current scanning, teams evaluating existing tools, or security leaders seeking broader visibility across repositories. Running it provides a quick, no-cost baseline for prioritizing security work.

Read original(opens in new tab)

GitHub ActionsStatic AnalysisSecret ScanningCodeql+3

github·Apr 13, 2026·1 min readCurated summary

GitHub for Beginners: Getting started with GitHub Pages

Kedasha is a GitHub Developer Advocate who shares her software development experience and industry knowledge with the broader developer community. She is passionate about helping others learn and can be found online as **@itsthatladydev**. ### Role and Focus - Works as a Developer Advocate at GitHub. - Shares lessons from her professional experience with developers. - Helps others learn about the technology industry. ### Online Presence - Identifies online as **@itsthatladydev**.

Read original(opens in new tab)

GithubSoftware DevelopmentDeveloper AdvocateCommunity Engagement+1

github·Apr 10, 2026·3 min readCurated summary

GitHub Copilot CLI for Beginners: Getting started with GitHub Copilot CLI

GitHub Copilot CLI brings Copilot’s agentic coding capabilities directly into the terminal, allowing developers to inspect projects, generate code, run tests, and correct errors without switching tools. The post introduces the tool, explains installation and authentication, and demonstrates how to use it for project overviews, coding tasks, and delegated work. Its central message is that Copilot CLI can preserve development flow while supporting increasingly autonomous coding workflows. ## What GitHub Copilot CLI Does - Runs Copilot from a command-line interface with context from the current repository. - Can autonomously: - Build or modify code - Run tests - Detect and correct errors - Explore project files and documentation - Lets developers review results and request follow-up changes directly in the terminal. - Can delegate well-defined tasks to the Copilot cloud agent. ## Installing Copilot CLI - The primary cross-platform installation method, assuming Node.js is available, is: ```bash npm install -g @github/copilot ``` - Users can also install it through package managers such as Homebrew or WinGet. ## First-Time Setup - Launch the tool by entering `Copilot` in the terminal. - Authenticate with GitHub using: ```plaintext /login ``` - Authentication connects the CLI to the user’s Copilot account and the read-only GitHub MCP server. - Copilot must be granted permission to access the current folder so it can inspect or modify files. - Folder permissions can apply only to the current session or be saved for future sessions. ## Common Development Tasks - **Understand an existing project** - Prompt Copilot with: ```plaintext Give me an overview of this project ``` - It examines important files and summarizes the project structure and purpose. - **Generate new code** - For example: ```plaintext Let’s add a new endpoint to return all categories ``` - Copilot reviews existing conventions, documentation, and examples before proposing or creating files. - It requests permission before making changes. - **Delegate work to the cloud agent** - A task can be sent using: ```plaintext /delegate Let’s deal with issue #14 to add the rest of the CRUD endpoints to games ``` - The cloud agent retains the current context, creates a branch, opens a draft pull request, and performs the work in the background for later review. ## What Comes Next The broader beginner series will cover interactive mode, non-interactive mode using the `-p` flag, slash commands, and MCP server integration. These features expand Copilot CLI from an interactive coding assistant into a flexible terminal-based automation tool. Copilot CLI is recommended for developers who want AI assistance without leaving the shell: install it with npm, authenticate, grant project permissions, and begin with exploratory prompts before assigning code changes or delegated tasks.

Read original(opens in new tab)

Model Context ProtocolGithub Copilot CliNode.JsNpm+3