{"owner":"google","repo":"gvisor","hasSkills":true,"totalSkillsCount":4,"totalTokensCount":3544,"categories":["root-instruction","mcp-config","marketplace","plugin-manifest"],"hasMcp":true,"mcpConfig":{"mcpServers":{"gvisor":{"command":"npx","args":["-y","@modelcontextprotocol/server-gvisor"]}}},"found":["AGENTS.md",".cursor/mcp.json",".claude-plugin/marketplace.json",".claude-plugin/plugin.json"],"skills":{"AGENTS.md":"# gVisor\n\n### What is gVisor?\n\ngVisor is a userspace kernel used for sandboxing untrusted programs. It is\nLinux-like kernel implementation in Go.\n\nNOTE: The project uses [Bazel](https://bazel.build/) as a build system, so paths\nstarting with `//` refer to the repository root, and `//some/path:some_target`\nrefers to target `some_target` defined inside `some/path/BUILD`.\n\ngVisor is made of multiple components:\n\n-   The gVisor Sentry is the main component implementing a Linux-like kernel in\n    Go. Its implementation is at `//pkg/sentry`.\n-   Gofers are I/O proxies for the gVisor Sentry. There are multiple Gofers, but\n    an implementation of one is at `//runsc/fsgofer`.\n-   `runsc` is a Docker-compatible OCI-compliant container runtime that uses\n    gVisor under the hood. It is useful to run Docker images in gVisor.\n    Location: `//runsc`.\n\n### Important gVisor subpackages\n\n-   The gVisor \"platform\" acts as a syscall interception mechanism for sandboxed\n    applications, and which is responsible for redirecting control to the gVisor\n    sentry for handling the system call. There are multiple platform\n    implementations; the name \"platform\" refers to the abstraction. Location:\n    `//pkg/sentry/platform`\n-   The gVisor `kernel` package implements the bulk of the kernel logic.\n    Location: `//pkg/sentry/kernel`\n-   The Linux kernel ABI is redefined as a Go package so that we can use it in\n    the gVisor kernel. Location: `//pkg/abi`.\n-   The `runsc` CLI is the main entry-point into gVisor for most usage.\n-   gVisor may also be used programmatically using a subprocess-like API via\n    language bindings with the `sandboxexec` API; see `//sandboxexec`.\n\n### gVisor code conventions\n\nSee `//.gemini/styleguide.md` for a general style guide.\n\nIn the gVisor codebase, all Go packages use the same package name as the name of\ntheir parent directory. For example:\n\n-   The package at `//pkg/errors/linuxerr` (which is the same as the BUILD\n    target `//pkg/errors/linuxerr:linuxerr`) has Go import path\n    `gvisor.dev/gvisor/pkg/errors/linuxerr`.\n-   The package at `//pkg/sentry/vfs` has Go import path\n    `gvisor.dev/gvisor/pkg/sentry/vfs`.\n-   This implies that new libraries you may create must be under their own new\n    subfolder. For example, if you wish to create a library called `foo` under\n    an existing directory `//pkg/bar`, you should create the directory\n    `//pkg/bar/foo` and then create a file `//pkg/bar/foo/foo.go` within it. The\n    `BUILD` file at `//pkg/bar/foo/BUILD` would contain the `go_library` rule\n    with name `foo`, and the `package` line within `//pkg/bar/foo/foo.go` would\n    be `package foo`. The import statement for this package in other Go\n    libraries would be `gvisor.dev/gvisor/pkg/bar/foo`, and the dependency\n    target would be `//pkg/bar/foo`. Other Go source files within\n    `//pkg/bar/foo` generally also belong to the same Go package, though it is\n    also acceptable to use the `foo_test` package name for test files in the\n    same `//pkg/bar/foo` directory, if having a separate package name is\n    desirable.\n-   gVisor's Bazel rules are wrappers over the usual ones, especially for\n    `go_library`, `go_binary`, and `go_test`. They should be imported into\n    `BUILD` files from `//tools:defs.bzl`, e.g. `load(\"//tools:defs.bzl\",\n    \"go_library\")` for the `go_library` wrapper. These wrapper rules create\n    auto-generated Go source files that are added to the source code of each Go\n    package, enabling code generation for Go code that gets injected into every\n    package, such as automated serialization. You generally do not need to\n    inspect these autogenerated Go source files, but be aware that they exist,\n    and that what you see in the repository is not the entire picture that the\n    Go compiler actually sees.\n-   When writing tests that need to read external files as input, you should use\n    the `testutil.FindFile` function defined in `//pkg/test/testutil` with\n    import path `gvisor.dev/gvisor/pkg/test/testutil`. It takes in a path as\n    argument, which is rooted from the `//` directory. For example, to access\n    file `//foo/bar/baz.txt`, you would call\n    `testutil.FindFile(\"foo/bar/baz.txt\")`. Every external file that you expect\n    to be able to find using `testutil.FindFile` must also be declared as a\n    `data` dependency in the `BUILD` target of the `go_test` target you are\n    editing. For example, to access file `//foo/bar/baz.txt`, the `go_test`\n    BUILD rule would need to have `data = [\"//foo/bar:baz.txt\"]`. If you want an\n    example, look at existing usages of this function to understand how it\n    works, e.g. `dumpfilter_test.go` in `//runsc/boot/filter/dumpfilter`.\n-   Despite being a bazel project, gVisor uses a Docker-based wrapper over bazel\n    using `make`. The `Makefile` defines wrapper rules over `bazel` subcommands,\n    which run these commands inside an automatically-managed Docker container.\n    This container is useful to smooth over Bazel quirks and version differences\n    across machines. For example, building a target is `make build\n    TARGETS=//path/to:target`, and running a test is `make test\n    TARGETS=//path/to:some_test`.\n-   Comments must describe the code as it is for the future codebase readers,\n    not for present-time PR reviewers. A comment that talks about a bug that the\n    PR at hand fixes is counter-productive, because it leaves behind irrelevant\n    historical context that future readers of the codebase should no longer have\n    to worry about.\n-   Function/struct/field comments should generally not refer to their callers\n    (e.g. \"Used by\", \"Useful for\"). If this is not already clear from the\n    function name or context, then the function name and/or context is the\n    problem, and the comment is a band-aid.\n-   Prose (such as comments, documentation, other markdown files) should mostly\n    follow ASD-STE100 Simplified Technical English. Some liberties are expected\n    (and welcome in some contexts, such as website/blog post contents), but\n    technical content should be crisp, clear, and to-the-point.\n-   gVisor is packaged as a fileset at `//:release`, and any consumers of this\n    must treat this as an opaque, all-or-nothing set of files to install or set\n    up. With narrow exceptions, they should not enumerate the set of files\n    within.\n\n### General approach to resolving gVisor issues\n\n#### Modifying gVisor kernel behavior\n\nUse the `gvisor-kernel-development` skill.\n\n#### Security first\n\nAll changes are reviewed for security. gVisor's design and architecture ensures\nthat a Sentry compromise, however unlikely, is still tightly contained.\nNonetheless, any changes to the Sentry are very security-sensitive and must be\nreviewed carefully to avoid introducing new escalation vectors. See\n`SECURITY.md` for various aspects of gVisor security.\n\n#### Compatibility in practice\n\ngVisor aims to match broad Linux-like behavior, but this is a moving target and\nsome incompatibilities matter more than others in practice. If there exists no\npopular real-world application that runs into the compatibility problem that a\nPR is addressing, the PR review will be de-prioritized against those that do\nhave popular real-world applications.\n\nThe pecking order, from most important to least, with compatibility code:\n\n-   `COMPATIBILITY:REGRESSION-GVISOR`: Regressions in real-world application\n    compatibility of a previously-supported application, due to past changes in\n    gVisor\n-   `COMPATIBILITY:REGRESSION-APP`: Regressions in real-world application\n    compatibility of a previously-supported application, due to changes/updates\n    by the application\n-   `COMPATIBILITY:UPCOMING-KERNEL`: Incompatibilities not yet encountered, but\n    known to later be encountered due to an upcoming change in the Linux kernel.\n-   `COMPATIBILITY:NEW-APP`: Incompatibilities encountered in real-world\n    applications that never worked in gVisor before, in their default\n    configuration/use-case.\n-   `COMPATIBILITY:NEW-APP-CONFIG`: Incompatibilities encountered in real-world\n    applications that never worked in gVisor before, in a specific non-default\n    configuration/use-case.\n-   `COMPATIBILITY:PREVENTIVE-APP`: Syscall-test-only change that verifies a\n    piece of **working** gVisor compatibility that isn't yet covered by syscall\n    tests, which is known to be relied upon by a real-world application.\n-   `COMPATIBILITY:UPCOMING-APP`: Incompatibilities not yet encountered, but\n    known to later be encountered due to an upcoming change in an application\n    that currently works in gVisor.\n-   `COMPATIBILITY:SYNTHETIC`: Incompatibilities exercisable only via syscall\n    tests, which no known real-world application encounters.\n\n#### Performance sensitivity\n\nAs a kernel, gVisor performance matters almost as much as security. As such, any\nchange that may impact performance is required to come with benchmark\nmeasurements to measure its benefit and to avoid regressions.\n\nThe following code is particularly performance-sensitive:\n\n-   The system call hot path: entry and dispatch in `pkg/sentry/kernel`\n    (`task_run.go`, `task_syscall.go`), the handlers in\n    `pkg/sentry/syscalls/linux`, and the layers that copy data to and from\n    application memory (`pkg/usermem`, `pkg/safemem`, `pkg/safecopy`,\n    `pkg/marshal`).\n-   Platform code (`pkg/sentry/platform`, `pkg/ring0`).\n-   Serialization code (`pkg/state`).\n-   Sandbox startup (`runsc/boot`, `runsc/container`, `runsc/sandbox`).\n-   Netstack (`pkg/tcpip`).\n-   Checkpoint/restore (`pkg/state`, `pkg/sentry/state`).\n-   File I/O (`pkg/sentry/vfs`, `pkg/sentry/fsimpl`).\n-   Memory management (`pkg/sentry/mm`, `pkg/sentry/pgalloc`).\n-   Inter-process communication with the gofer (`pkg/lisafs`, `runsc/fsgofer`).\n-   Go `init()` functions that run on every binary startup.\n\nLoad the `gvisor-performance` skill whenever any of these paths show up, or when\na change has any possibility of performance implications. Test-only changes do\nnot have performance implications.\n\n## Git / GitHub / PR Guidelines\n\nBefore sending PRs, check the following:\n\n-   Compatibility fixes must come with a compatibility code (see \"Compatibility\n    in practice\" section), along with an explanation for this code.\n-   Syscall behavior must be verified to match Linux behavior by way of syscall\n    tests, not Go tests.\n-   Everything must build; use `make build TARGETS=...` building affected paths.\n-   Relevant tests must pass; use `make test TARGETS=...` or `make syscall-tests\n    TARGETS=...` as appropriate.\n-   All PRs must pass `make lint` and `make lint-cc`.\n-   When benchmarks are required, they must come with statistically-significant\n    figures. See section on performance changes.\n-   Website changes should come with before/after screenshots (use `make\n    website-server` to start an HTTP server serving the site locally).\n-   Test-only changes that improve stability/flakiness are very much welcome.\n",".cursor/mcp.json":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/google/gvisor/HEAD/.cursor/mcp.json)",".claude-plugin/marketplace.json":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/google/gvisor/HEAD/.claude-plugin/marketplace.json)",".claude-plugin/plugin.json":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/google/gvisor/HEAD/.claude-plugin/plugin.json)"},"files":{"AGENTS.md":"# gVisor\n\n### What is gVisor?\n\ngVisor is a userspace kernel used for sandboxing untrusted programs. It is\nLinux-like kernel implementation in Go.\n\nNOTE: The project uses [Bazel](https://bazel.build/) as a build system, so paths\nstarting with `//` refer to the repository root, and `//some/path:some_target`\nrefers to target `some_target` defined inside `some/path/BUILD`.\n\ngVisor is made of multiple components:\n\n-   The gVisor Sentry is the main component implementing a Linux-like kernel in\n    Go. Its implementation is at `//pkg/sentry`.\n-   Gofers are I/O proxies for the gVisor Sentry. There are multiple Gofers, but\n    an implementation of one is at `//runsc/fsgofer`.\n-   `runsc` is a Docker-compatible OCI-compliant container runtime that uses\n    gVisor under the hood. It is useful to run Docker images in gVisor.\n    Location: `//runsc`.\n\n### Important gVisor subpackages\n\n-   The gVisor \"platform\" acts as a syscall interception mechanism for sandboxed\n    applications, and which is responsible for redirecting control to the gVisor\n    sentry for handling the system call. There are multiple platform\n    implementations; the name \"platform\" refers to the abstraction. Location:\n    `//pkg/sentry/platform`\n-   The gVisor `kernel` package implements the bulk of the kernel logic.\n    Location: `//pkg/sentry/kernel`\n-   The Linux kernel ABI is redefined as a Go package so that we can use it in\n    the gVisor kernel. Location: `//pkg/abi`.\n-   The `runsc` CLI is the main entry-point into gVisor for most usage.\n-   gVisor may also be used programmatically using a subprocess-like API via\n    language bindings with the `sandboxexec` API; see `//sandboxexec`.\n\n### gVisor code conventions\n\nSee `//.gemini/styleguide.md` for a general style guide.\n\nIn the gVisor codebase, all Go packages use the same package name as the name of\ntheir parent directory. For example:\n\n-   The package at `//pkg/errors/linuxerr` (which is the same as the BUILD\n    target `//pkg/errors/linuxerr:linuxerr`) has Go import path\n    `gvisor.dev/gvisor/pkg/errors/linuxerr`.\n-   The package at `//pkg/sentry/vfs` has Go import path\n    `gvisor.dev/gvisor/pkg/sentry/vfs`.\n-   This implies that new libraries you may create must be under their own new\n    subfolder. For example, if you wish to create a library called `foo` under\n    an existing directory `//pkg/bar`, you should create the directory\n    `//pkg/bar/foo` and then create a file `//pkg/bar/foo/foo.go` within it. The\n    `BUILD` file at `//pkg/bar/foo/BUILD` would contain the `go_library` rule\n    with name `foo`, and the `package` line within `//pkg/bar/foo/foo.go` would\n    be `package foo`. The import statement for this package in other Go\n    libraries would be `gvisor.dev/gvisor/pkg/bar/foo`, and the dependency\n    target would be `//pkg/bar/foo`. Other Go source files within\n    `//pkg/bar/foo` generally also belong to the same Go package, though it is\n    also acceptable to use the `foo_test` package name for test files in the\n    same `//pkg/bar/foo` directory, if having a separate package name is\n    desirable.\n-   gVisor's Bazel rules are wrappers over the usual ones, especially for\n    `go_library`, `go_binary`, and `go_test`. They should be imported into\n    `BUILD` files from `//tools:defs.bzl`, e.g. `load(\"//tools:defs.bzl\",\n    \"go_library\")` for the `go_library` wrapper. These wrapper rules create\n    auto-generated Go source files that are added to the source code of each Go\n    package, enabling code generation for Go code that gets injected into every\n    package, such as automated serialization. You generally do not need to\n    inspect these autogenerated Go source files, but be aware that they exist,\n    and that what you see in the repository is not the entire picture that the\n    Go compiler actually sees.\n-   When writing tests that need to read external files as input, you should use\n    the `testutil.FindFile` function defined in `//pkg/test/testutil` with\n    import path `gvisor.dev/gvisor/pkg/test/testutil`. It takes in a path as\n    argument, which is rooted from the `//` directory. For example, to access\n    file `//foo/bar/baz.txt`, you would call\n    `testutil.FindFile(\"foo/bar/baz.txt\")`. Every external file that you expect\n    to be able to find using `testutil.FindFile` must also be declared as a\n    `data` dependency in the `BUILD` target of the `go_test` target you are\n    editing. For example, to access file `//foo/bar/baz.txt`, the `go_test`\n    BUILD rule would need to have `data = [\"//foo/bar:baz.txt\"]`. If you want an\n    example, look at existing usages of this function to understand how it\n    works, e.g. `dumpfilter_test.go` in `//runsc/boot/filter/dumpfilter`.\n-   Despite being a bazel project, gVisor uses a Docker-based wrapper over bazel\n    using `make`. The `Makefile` defines wrapper rules over `bazel` subcommands,\n    which run these commands inside an automatically-managed Docker container.\n    This container is useful to smooth over Bazel quirks and version differences\n    across machines. For example, building a target is `make build\n    TARGETS=//path/to:target`, and running a test is `make test\n    TARGETS=//path/to:some_test`.\n-   Comments must describe the code as it is for the future codebase readers,\n    not for present-time PR reviewers. A comment that talks about a bug that the\n    PR at hand fixes is counter-productive, because it leaves behind irrelevant\n    historical context that future readers of the codebase should no longer have\n    to worry about.\n-   Function/struct/field comments should generally not refer to their callers\n    (e.g. \"Used by\", \"Useful for\"). If this is not already clear from the\n    function name or context, then the function name and/or context is the\n    problem, and the comment is a band-aid.\n-   Prose (such as comments, documentation, other markdown files) should mostly\n    follow ASD-STE100 Simplified Technical English. Some liberties are expected\n    (and welcome in some contexts, such as website/blog post contents), but\n    technical content should be crisp, clear, and to-the-point.\n-   gVisor is packaged as a fileset at `//:release`, and any consumers of this\n    must treat this as an opaque, all-or-nothing set of files to install or set\n    up. With narrow exceptions, they should not enumerate the set of files\n    within.\n\n### General approach to resolving gVisor issues\n\n#### Modifying gVisor kernel behavior\n\nUse the `gvisor-kernel-development` skill.\n\n#### Security first\n\nAll changes are reviewed for security. gVisor's design and architecture ensures\nthat a Sentry compromise, however unlikely, is still tightly contained.\nNonetheless, any changes to the Sentry are very security-sensitive and must be\nreviewed carefully to avoid introducing new escalation vectors. See\n`SECURITY.md` for various aspects of gVisor security.\n\n#### Compatibility in practice\n\ngVisor aims to match broad Linux-like behavior, but this is a moving target and\nsome incompatibilities matter more than others in practice. If there exists no\npopular real-world application that runs into the compatibility problem that a\nPR is addressing, the PR review will be de-prioritized against those that do\nhave popular real-world applications.\n\nThe pecking order, from most important to least, with compatibility code:\n\n-   `COMPATIBILITY:REGRESSION-GVISOR`: Regressions in real-world application\n    compatibility of a previously-supported application, due to past changes in\n    gVisor\n-   `COMPATIBILITY:REGRESSION-APP`: Regressions in real-world application\n    compatibility of a previously-supported application, due to changes/updates\n    by the application\n-   `COMPATIBILITY:UPCOMING-KERNEL`: Incompatibilities not yet encountered, but\n    known to later be encountered due to an upcoming change in the Linux kernel.\n-   `COMPATIBILITY:NEW-APP`: Incompatibilities encountered in real-world\n    applications that never worked in gVisor before, in their default\n    configuration/use-case.\n-   `COMPATIBILITY:NEW-APP-CONFIG`: Incompatibilities encountered in real-world\n    applications that never worked in gVisor before, in a specific non-default\n    configuration/use-case.\n-   `COMPATIBILITY:PREVENTIVE-APP`: Syscall-test-only change that verifies a\n    piece of **working** gVisor compatibility that isn't yet covered by syscall\n    tests, which is known to be relied upon by a real-world application.\n-   `COMPATIBILITY:UPCOMING-APP`: Incompatibilities not yet encountered, but\n    known to later be encountered due to an upcoming change in an application\n    that currently works in gVisor.\n-   `COMPATIBILITY:SYNTHETIC`: Incompatibilities exercisable only via syscall\n    tests, which no known real-world application encounters.\n\n#### Performance sensitivity\n\nAs a kernel, gVisor performance matters almost as much as security. As such, any\nchange that may impact performance is required to come with benchmark\nmeasurements to measure its benefit and to avoid regressions.\n\nThe following code is particularly performance-sensitive:\n\n-   The system call hot path: entry and dispatch in `pkg/sentry/kernel`\n    (`task_run.go`, `task_syscall.go`), the handlers in\n    `pkg/sentry/syscalls/linux`, and the layers that copy data to and from\n    application memory (`pkg/usermem`, `pkg/safemem`, `pkg/safecopy`,\n    `pkg/marshal`).\n-   Platform code (`pkg/sentry/platform`, `pkg/ring0`).\n-   Serialization code (`pkg/state`).\n-   Sandbox startup (`runsc/boot`, `runsc/container`, `runsc/sandbox`).\n-   Netstack (`pkg/tcpip`).\n-   Checkpoint/restore (`pkg/state`, `pkg/sentry/state`).\n-   File I/O (`pkg/sentry/vfs`, `pkg/sentry/fsimpl`).\n-   Memory management (`pkg/sentry/mm`, `pkg/sentry/pgalloc`).\n-   Inter-process communication with the gofer (`pkg/lisafs`, `runsc/fsgofer`).\n-   Go `init()` functions that run on every binary startup.\n\nLoad the `gvisor-performance` skill whenever any of these paths show up, or when\na change has any possibility of performance implications. Test-only changes do\nnot have performance implications.\n\n## Git / GitHub / PR Guidelines\n\nBefore sending PRs, check the following:\n\n-   Compatibility fixes must come with a compatibility code (see \"Compatibility\n    in practice\" section), along with an explanation for this code.\n-   Syscall behavior must be verified to match Linux behavior by way of syscall\n    tests, not Go tests.\n-   Everything must build; use `make build TARGETS=...` building affected paths.\n-   Relevant tests must pass; use `make test TARGETS=...` or `make syscall-tests\n    TARGETS=...` as appropriate.\n-   All PRs must pass `make lint` and `make lint-cc`.\n-   When benchmarks are required, they must come with statistically-significant\n    figures. See section on performance changes.\n-   Website changes should come with before/after screenshots (use `make\n    website-server` to start an HTTP server serving the site locally).\n-   Test-only changes that improve stability/flakiness are very much welcome.\n",".cursor/mcp.json":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/google/gvisor/HEAD/.cursor/mcp.json)",".claude-plugin/marketplace.json":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/google/gvisor/HEAD/.claude-plugin/marketplace.json)",".claude-plugin/plugin.json":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/google/gvisor/HEAD/.claude-plugin/plugin.json)"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/google/gvisor/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# gVisor\n\n### What is gVisor?\n\ngVisor is a userspace kernel used for sandboxing untrusted programs. It is\nLinux-like kernel implementation in Go.\n\nNOTE: The project uses [Bazel](https://bazel.build/) as a build system, so paths\nstarting with `//` refer to the repository root, and `//some/path:some_target`\nrefers to target `some_target` defined inside `some/path/BUILD`.\n\ngVisor is made of multiple components:\n\n-   The gVisor Sentry is the main component implementing a Linux-like kernel in\n    Go. Its implementation is at `//pkg/sentry`.\n-   Gofers are I/O proxies for the gVisor Sentry. There are multiple Gofers, but\n    an implementation of one is at `//runsc/fsgofer`.\n-   `runsc` is a Docker-compatible OCI-compliant container runtime that uses\n    gVisor under the hood. It is useful to run Docker images in gVisor.\n    Location: `//runsc`.\n\n### Important gVisor subpackages\n\n-   The gVisor \"platform\" acts as a syscall interception mechanism for sandboxed\n    applications, and which is responsible for redirecting control to the gVisor\n    sentry for handling the system call. There are multiple platform\n    implementations; the name \"platform\" refers to the abstraction. Location:\n    `//pkg/sentry/platform`\n-   The gVisor `kernel` package implements the bulk of the kernel logic.\n    Location: `//pkg/sentry/kernel`\n-   The Linux kernel ABI is redefined as a Go package so that we can use it in\n    the gVisor kernel. Location: `//pkg/abi`.\n-   The `runsc` CLI is the main entry-point into gVisor for most usage.\n-   gVisor may also be used programmatically using a subprocess-like API via\n    language bindings with the `sandboxexec` API; see `//sandboxexec`.\n\n### gVisor code conventions\n\nSee `//.gemini/styleguide.md` for a general style guide.\n\nIn the gVisor codebase, all Go packages use the same package name as the name of\ntheir parent directory. For example:\n\n-   The package at `//pkg/errors/linuxerr` (which is the same as the BUILD\n    target `//pkg/errors/linuxerr:linuxerr`) has Go import path\n    `gvisor.dev/gvisor/pkg/errors/linuxerr`.\n-   The package at `//pkg/sentry/vfs` has Go import path\n    `gvisor.dev/gvisor/pkg/sentry/vfs`.\n-   This implies that new libraries you may create must be under their own new\n    subfolder. For example, if you wish to create a library called `foo` under\n    an existing directory `//pkg/bar`, you should create the directory\n    `//pkg/bar/foo` and then create a file `//pkg/bar/foo/foo.go` within it. The\n    `BUILD` file at `//pkg/bar/foo/BUILD` would contain the `go_library` rule\n    with name `foo`, and the `package` line within `//pkg/bar/foo/foo.go` would\n    be `package foo`. The import statement for this package in other Go\n    libraries would be `gvisor.dev/gvisor/pkg/bar/foo`, and the dependency\n    target would be `//pkg/bar/foo`. Other Go source files within\n    `//pkg/bar/foo` generally also belong to the same Go package, though it is\n    also acceptable to use the `foo_test` package name for test files in the\n    same `//pkg/bar/foo` directory, if having a separate package name is\n    desirable.\n-   gVisor's Bazel rules are wrappers over the usual ones, especially for\n    `go_library`, `go_binary`, and `go_test`. They should be imported into\n    `BUILD` files from `//tools:defs.bzl`, e.g. `load(\"//tools:defs.bzl\",\n    \"go_library\")` for the `go_library` wrapper. These wrapper rules create\n    auto-generated Go source files that are added to the source code of each Go\n    package, enabling code generation for Go code that gets injected into every\n    package, such as automated serialization. You generally do not need to\n    inspect these autogenerated Go source files, but be aware that they exist,\n    and that what you see in the repository is not the entire picture that the\n    Go compiler actually sees.\n-   When writing tests that need to read external files as input, you should use\n    the `testutil.FindFile` function defined in `//pkg/test/testutil` with\n    import path `gvisor.dev/gvisor/pkg/test/testutil`. It takes in a path as\n    argument, which is rooted from the `//` directory. For example, to access\n    file `//foo/bar/baz.txt`, you would call\n    `testutil.FindFile(\"foo/bar/baz.txt\")`. Every external file that you expect\n    to be able to find using `testutil.FindFile` must also be declared as a\n    `data` dependency in the `BUILD` target of the `go_test` target you are\n    editing. For example, to access file `//foo/bar/baz.txt`, the `go_test`\n    BUILD rule would need to have `data = [\"//foo/bar:baz.txt\"]`. If you want an\n    example, look at existing usages of this function to understand how it\n    works, e.g. `dumpfilter_test.go` in `//runsc/boot/filter/dumpfilter`.\n-   Despite being a bazel project, gVisor uses a Docker-based wrapper over bazel\n    using `make`. The `Makefile` defines wrapper rules over `bazel` subcommands,\n    which run these commands inside an automatically-managed Docker container.\n    This container is useful to smooth over Bazel quirks and version differences\n    across machines. For example, building a target is `make build\n    TARGETS=//path/to:target`, and running a test is `make test\n    TARGETS=//path/to:some_test`.\n-   Comments must describe the code as it is for the future codebase readers,\n    not for present-time PR reviewers. A comment that talks about a bug that the\n    PR at hand fixes is counter-productive, because it leaves behind irrelevant\n    historical context that future readers of the codebase should no longer have\n    to worry about.\n-   Function/struct/field comments should generally not refer to their callers\n    (e.g. \"Used by\", \"Useful for\"). If this is not already clear from the\n    function name or context, then the function name and/or context is the\n    problem, and the comment is a band-aid.\n-   Prose (such as comments, documentation, other markdown files) should mostly\n    follow ASD-STE100 Simplified Technical English. Some liberties are expected\n    (and welcome in some contexts, such as website/blog post contents), but\n    technical content should be crisp, clear, and to-the-point.\n-   gVisor is packaged as a fileset at `//:release`, and any consumers of this\n    must treat this as an opaque, all-or-nothing set of files to install or set\n    up. With narrow exceptions, they should not enumerate the set of files\n    within.\n\n### General approach to resolving gVisor issues\n\n#### Modifying gVisor kernel behavior\n\nUse the `gvisor-kernel-development` skill.\n\n#### Security first\n\nAll changes are reviewed for security. gVisor's design and architecture ensures\nthat a Sentry compromise, however unlikely, is still tightly contained.\nNonetheless, any changes to the Sentry are very security-sensitive and must be\nreviewed carefully to avoid introducing new escalation vectors. See\n`SECURITY.md` for various aspects of gVisor security.\n\n#### Compatibility in practice\n\ngVisor aims to match broad Linux-like behavior, but this is a moving target and\nsome incompatibilities matter more than others in practice. If there exists no\npopular real-world application that runs into the compatibility problem that a\nPR is addressing, the PR review will be de-prioritized against those that do\nhave popular real-world applications.\n\nThe pecking order, from most important to least, with compatibility code:\n\n-   `COMPATIBILITY:REGRESSION-GVISOR`: Regressions in real-world application\n    compatibility of a previously-supported application, due to past changes in\n    gVisor\n-   `COMPATIBILITY:REGRESSION-APP`: Regressions in real-world application\n    compatibility of a previously-supported application, due to changes/updates\n    by the application\n-   `COMPATIBILITY:UPCOMING-KERNEL`: Incompatibilities not yet encountered, but\n    known to later be encountered due to an upcoming change in the Linux kernel.\n-   `COMPATIBILITY:NEW-APP`: Incompatibilities encountered in real-world\n    applications that never worked in gVisor before, in their default\n    configuration/use-case.\n-   `COMPATIBILITY:NEW-APP-CONFIG`: Incompatibilities encountered in real-world\n    applications that never worked in gVisor before, in a specific non-default\n    configuration/use-case.\n-   `COMPATIBILITY:PREVENTIVE-APP`: Syscall-test-only change that verifies a\n    piece of **working** gVisor compatibility that isn't yet covered by syscall\n    tests, which is known to be relied upon by a real-world application.\n-   `COMPATIBILITY:UPCOMING-APP`: Incompatibilities not yet encountered, but\n    known to later be encountered due to an upcoming change in an application\n    that currently works in gVisor.\n-   `COMPATIBILITY:SYNTHETIC`: Incompatibilities exercisable only via syscall\n    tests, which no known real-world application encounters.\n\n#### Performance sensitivity\n\nAs a kernel, gVisor performance matters almost as much as security. As such, any\nchange that may impact performance is required to come with benchmark\nmeasurements to measure its benefit and to avoid regressions.\n\nThe following code is particularly performance-sensitive:\n\n-   The system call hot path: entry and dispatch in `pkg/sentry/kernel`\n    (`task_run.go`, `task_syscall.go`), the handlers in\n    `pkg/sentry/syscalls/linux`, and the layers that copy data to and from\n    application memory (`pkg/usermem`, `pkg/safemem`, `pkg/safecopy`,\n    `pkg/marshal`).\n-   Platform code (`pkg/sentry/platform`, `pkg/ring0`).\n-   Serialization code (`pkg/state`).\n-   Sandbox startup (`runsc/boot`, `runsc/container`, `runsc/sandbox`).\n-   Netstack (`pkg/tcpip`).\n-   Checkpoint/restore (`pkg/state`, `pkg/sentry/state`).\n-   File I/O (`pkg/sentry/vfs`, `pkg/sentry/fsimpl`).\n-   Memory management (`pkg/sentry/mm`, `pkg/sentry/pgalloc`).\n-   Inter-process communication with the gofer (`pkg/lisafs`, `runsc/fsgofer`).\n-   Go `init()` functions that run on every binary startup.\n\nLoad the `gvisor-performance` skill whenever any of these paths show up, or when\na change has any possibility of performance implications. Test-only changes do\nnot have performance implications.\n\n## Git / GitHub / PR Guidelines\n\nBefore sending PRs, check the following:\n\n-   Compatibility fixes must come with a compatibility code (see \"Compatibility\n    in practice\" section), along with an explanation for this code.\n-   Syscall behavior must be verified to match Linux behavior by way of syscall\n    tests, not Go tests.\n-   Everything must build; use `make build TARGETS=...` building affected paths.\n-   Relevant tests must pass; use `make test TARGETS=...` or `make syscall-tests\n    TARGETS=...` as appropriate.\n-   All PRs must pass `make lint` and `make lint-cc`.\n-   When benchmarks are required, they must come with statistically-significant\n    figures. See section on performance changes.\n-   Website changes should come with before/after screenshots (use `make\n    website-server` to start an HTTP server serving the site locally).\n-   Test-only changes that improve stability/flakiness are very much welcome.\n","isInternal":false,"tokens":2644,"sizeBytes":10976},{"name":"marketplace.json","path":".claude-plugin/marketplace.json","rawUrl":"https://raw.githubusercontent.com/google/gvisor/HEAD/.claude-plugin/marketplace.json","title":"Claude Plugin Marketplace Catalog","category":"marketplace","format":"json","content":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/google/gvisor/HEAD/.claude-plugin/marketplace.json)","tokens":300,"sizeBytes":192},{"name":"plugin.json","path":".claude-plugin/plugin.json","rawUrl":"https://raw.githubusercontent.com/google/gvisor/HEAD/.claude-plugin/plugin.json","title":"claude-plugin Plugin Manifest","category":"plugin-manifest","format":"json","content":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/google/gvisor/HEAD/.claude-plugin/plugin.json)","tokens":300,"sizeBytes":178},{"name":"mcp.json","path":".cursor/mcp.json","rawUrl":"https://raw.githubusercontent.com/google/gvisor/HEAD/.cursor/mcp.json","title":"Model Context Protocol (MCP) Configuration","category":"mcp-config","format":"json","content":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/google/gvisor/HEAD/.cursor/mcp.json)","tokens":300,"sizeBytes":171}],"systemPromptSnippet":"<yakaai_skills repo=\"google/gvisor\">\n<!-- File: AGENTS.md (Tokens: ~2644 | Category: root-instruction) -->\n# gVisor\n\n### What is gVisor?\n\ngVisor is a userspace kernel used for sandboxing untrusted programs. It is\nLinux-like kernel implementation in Go.\n\nNOTE: The project uses [Bazel](https://bazel.build/) as a build system, so paths\nstarting with `//` refer to the repository root, and `//some/path:some_target`\nrefers to target `some_target` defined inside `some/path/BUILD`.\n\ngVisor is made of multiple components:\n\n-   The gVisor Sentry is the main component implementing a Linux-like kernel in\n    Go. Its implementation is at `//pkg/sentry`.\n-   Gofers are I/O proxies for the gVisor Sentry. There are multiple Gofers, but\n    an implementation of one is at `//runsc/fsgofer`.\n-   `runsc` is a Docker-compatible OCI-compliant container runtime that uses\n    gVisor under the hood. It is useful to run Docker images in gVisor.\n    Location: `//runsc`.\n\n### Important gVisor subpackages\n\n-   The gVisor \"platform\" acts as a syscall interception mechanism for sandboxed\n    applications, and which is responsible for redirecting control to the gVisor\n    sentry for handling the system call. There are multiple platform\n    implementations; the name \"platform\" refers to the abstraction. Location:\n    `//pkg/sentry/platform`\n-   The gVisor `kernel` package implements the bulk of the kernel logic.\n    Location: `//pkg/sentry/kernel`\n-   The Linux kernel ABI is redefined as a Go package so that we can use it in\n    the gVisor kernel. Location: `//pkg/abi`.\n-   The `runsc` CLI is the main entry-point into gVisor for most usage.\n-   gVisor may also be used programmatically using a subprocess-like API via\n    language bindings with the `sandboxexec` API; see `//sandboxexec`.\n\n### gVisor code conventions\n\nSee `//.gemini/styleguide.md` for a general style guide.\n\nIn the gVisor codebase, all Go packages use the same package name as the name of\ntheir parent directory. For example:\n\n-   The package at `//pkg/errors/linuxerr` (which is the same as the BUILD\n    target `//pkg/errors/linuxerr:linuxerr`) has Go import path\n    `gvisor.dev/gvisor/pkg/errors/linuxerr`.\n-   The package at `//pkg/sentry/vfs` has Go import path\n    `gvisor.dev/gvisor/pkg/sentry/vfs`.\n-   This implies that new libraries you may create must be under their own new\n    subfolder. For example, if you wish to create a library called `foo` under\n    an existing directory `//pkg/bar`, you should create the directory\n    `//pkg/bar/foo` and then create a file `//pkg/bar/foo/foo.go` within it. The\n    `BUILD` file at `//pkg/bar/foo/BUILD` would contain the `go_library` rule\n    with name `foo`, and the `package` line within `//pkg/bar/foo/foo.go` would\n    be `package foo`. The import statement for this package in other Go\n    libraries would be `gvisor.dev/gvisor/pkg/bar/foo`, and the dependency\n    target would be `//pkg/bar/foo`. Other Go source files within\n    `//pkg/bar/foo` generally also belong to the same Go package, though it is\n    also acceptable to use the `foo_test` package name for test files in the\n    same `//pkg/bar/foo` directory, if having a separate package name is\n    desirable.\n-   gVisor's Bazel rules are wrappers over the usual ones, especially for\n    `go_library`, `go_binary`, and `go_test`. They should be imported into\n    `BUILD` files from `//tools:defs.bzl`, e.g. `load(\"//tools:defs.bzl\",\n    \"go_library\")` for the `go_library` wrapper. These wrapper rules create\n    auto-generated Go source files that are added to the source code of each Go\n    package, enabling code generation for Go code that gets injected into every\n    package, such as automated serialization. You generally do not need to\n    inspect these autogenerated Go source files, but be aware that they exist,\n    and that what you see in the repository is not the entire picture that the\n    Go compiler actually sees.\n-   When writing tests that need to read external files as input, you should use\n    the `testutil.FindFile` function defined in `//pkg/test/testutil` with\n    import path `gvisor.dev/gvisor/pkg/test/testutil`. It takes in a path as\n    argument, which is rooted from the `//` directory. For example, to access\n    file `//foo/bar/baz.txt`, you would call\n    `testutil.FindFile(\"foo/bar/baz.txt\")`. Every external file that you expect\n    to be able to find using `testutil.FindFile` must also be declared as a\n    `data` dependency in the `BUILD` target of the `go_test` target you are\n    editing. For example, to access file `//foo/bar/baz.txt`, the `go_test`\n    BUILD rule would need to have `data = [\"//foo/bar:baz.txt\"]`. If you want an\n    example, look at existing usages of this function to understand how it\n    works, e.g. `dumpfilter_test.go` in `//runsc/boot/filter/dumpfilter`.\n-   Despite being a bazel project, gVisor uses a Docker-based wrapper over bazel\n    using `make`. The `Makefile` defines wrapper rules over `bazel` subcommands,\n    which run these commands inside an automatically-managed Docker container.\n    This container is useful to smooth over Bazel quirks and version differences\n    across machines. For example, building a target is `make build\n    TARGETS=//path/to:target`, and running a test is `make test\n    TARGETS=//path/to:some_test`.\n-   Comments must describe the code as it is for the future codebase readers,\n    not for present-time PR reviewers. A comment that talks about a bug that the\n    PR at hand fixes is counter-productive, because it leaves behind irrelevant\n    historical context that future readers of the codebase should no longer have\n    to worry about.\n-   Function/struct/field comments should generally not refer to their callers\n    (e.g. \"Used by\", \"Useful for\"). If this is not already clear from the\n    function name or context, then the function name and/or context is the\n    problem, and the comment is a band-aid.\n-   Prose (such as comments, documentation, other markdown files) should mostly\n    follow ASD-STE100 Simplified Technical English. Some liberties are expected\n    (and welcome in some contexts, such as website/blog post contents), but\n    technical content should be crisp, clear, and to-the-point.\n-   gVisor is packaged as a fileset at `//:release`, and any consumers of this\n    must treat this as an opaque, all-or-nothing set of files to install or set\n    up. With narrow exceptions, they should not enumerate the set of files\n    within.\n\n### General approach to resolving gVisor issues\n\n#### Modifying gVisor kernel behavior\n\nUse the `gvisor-kernel-development` skill.\n\n#### Security first\n\nAll changes are reviewed for security. gVisor's design and architecture ensures\nthat a Sentry compromise, however unlikely, is still tightly contained.\nNonetheless, any changes to the Sentry are very security-sensitive and must be\nreviewed carefully to avoid introducing new escalation vectors. See\n`SECURITY.md` for various aspects of gVisor security.\n\n#### Compatibility in practice\n\ngVisor aims to match broad Linux-like behavior, but this is a moving target and\nsome incompatibilities matter more than others in practice. If there exists no\npopular real-world application that runs into the compatibility problem that a\nPR is addressing, the PR review will be de-prioritized against those that do\nhave popular real-world applications.\n\nThe pecking order, from most important to least, with compatibility code:\n\n-   `COMPATIBILITY:REGRESSION-GVISOR`: Regressions in real-world application\n    compatibility of a previously-supported application, due to past changes in\n    gVisor\n-   `COMPATIBILITY:REGRESSION-APP`: Regressions in real-world application\n    compatibility of a previously-supported application, due to changes/updates\n    by the application\n-   `COMPATIBILITY:UPCOMING-KERNEL`: Incompatibilities not yet encountered, but\n    known to later be encountered due to an upcoming change in the Linux kernel.\n-   `COMPATIBILITY:NEW-APP`: Incompatibilities encountered in real-world\n    applications that never worked in gVisor before, in their default\n    configuration/use-case.\n-   `COMPATIBILITY:NEW-APP-CONFIG`: Incompatibilities encountered in real-world\n    applications that never worked in gVisor before, in a specific non-default\n    configuration/use-case.\n-   `COMPATIBILITY:PREVENTIVE-APP`: Syscall-test-only change that verifies a\n    piece of **working** gVisor compatibility that isn't yet covered by syscall\n    tests, which is known to be relied upon by a real-world application.\n-   `COMPATIBILITY:UPCOMING-APP`: Incompatibilities not yet encountered, but\n    known to later be encountered due to an upcoming change in an application\n    that currently works in gVisor.\n-   `COMPATIBILITY:SYNTHETIC`: Incompatibilities exercisable only via syscall\n    tests, which no known real-world application encounters.\n\n#### Performance sensitivity\n\nAs a kernel, gVisor performance matters almost as much as security. As such, any\nchange that may impact performance is required to come with benchmark\nmeasurements to measure its benefit and to avoid regressions.\n\nThe following code is particularly performance-sensitive:\n\n-   The system call hot path: entry and dispatch in `pkg/sentry/kernel`\n    (`task_run.go`, `task_syscall.go`), the handlers in\n    `pkg/sentry/syscalls/linux`, and the layers that copy data to and from\n    application memory (`pkg/usermem`, `pkg/safemem`, `pkg/safecopy`,\n    `pkg/marshal`).\n-   Platform code (`pkg/sentry/platform`, `pkg/ring0`).\n-   Serialization code (`pkg/state`).\n-   Sandbox startup (`runsc/boot`, `runsc/container`, `runsc/sandbox`).\n-   Netstack (`pkg/tcpip`).\n-   Checkpoint/restore (`pkg/state`, `pkg/sentry/state`).\n-   File I/O (`pkg/sentry/vfs`, `pkg/sentry/fsimpl`).\n-   Memory management (`pkg/sentry/mm`, `pkg/sentry/pgalloc`).\n-   Inter-process communication with the gofer (`pkg/lisafs`, `runsc/fsgofer`).\n-   Go `init()` functions that run on every binary startup.\n\nLoad the `gvisor-performance` skill whenever any of these paths show up, or when\na change has any possibility of performance implications. Test-only changes do\nnot have performance implications.\n\n## Git / GitHub / PR Guidelines\n\nBefore sending PRs, check the following:\n\n-   Compatibility fixes must come with a compatibility code (see \"Compatibility\n    in practice\" section), along with an explanation for this code.\n-   Syscall behavior must be verified to match Linux behavior by way of syscall\n    tests, not Go tests.\n-   Everything must build; use `make build TARGETS=...` building affected paths.\n-   Relevant tests must pass; use `make test TARGETS=...` or `make syscall-tests\n    TARGETS=...` as appropriate.\n-   All PRs must pass `make lint` and `make lint-cc`.\n-   When benchmarks are required, they must come with statistically-significant\n    figures. See section on performance changes.\n-   Website changes should come with before/after screenshots (use `make\n    website-server` to start an HTTP server serving the site locally).\n-   Test-only changes that improve stability/flakiness are very much welcome.\n\n<!-- File: .claude-plugin/marketplace.json (Tokens: ~300 | Category: marketplace) -->\n# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/google/gvisor/HEAD/.claude-plugin/marketplace.json)\n\n<!-- File: .claude-plugin/plugin.json (Tokens: ~300 | Category: plugin-manifest) -->\n# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/google/gvisor/HEAD/.claude-plugin/plugin.json)\n\n<!-- File: .cursor/mcp.json (Tokens: ~300 | Category: mcp-config) -->\n# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/google/gvisor/HEAD/.cursor/mcp.json)\n</yakaai_skills>"}