Move sandbox manager tests to use a test directory and to clean up after

[kschaab]

Summary

Modifies the sandbox manager tests to use a temporary test directory and cleanup afterwards.

Details

This fixes the issue where the sandbox manager integration tests are orphaning files packages/core/.gitignore and packages/core/.geminiignore during a test run.

Related Issues

Fixes #25003

How to Validate

npm run test without change will result in these files.
npm run test with this change will no longer drop these files.

Pre-Merge Checklist

• Updated relevant documentation and README (if needed)
• Added/updated tests (if needed)
• Noted breaking changes (if any)
• Validated on required platforms/methods:
  • MacOS
    • npm run
    • npx
    • Docker
    • Podman
    • Seatbelt
  • Windows
    • npm run
    • npx
    • Docker
  • Linux
    • npm run
    • npx
    • Docker

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly improves the hygiene and reliability of the sandbox manager integration tests. By introducing a temporary workspace that is automatically created and cleaned up, it ensures that test runs do not leave behind residual files, addressing a known issue of file leakage and maintaining a clean development environment. This change enhances test isolation and prevents unintended side effects on the file system.

Highlights

• Test Environment Management: Modified the sandbox manager integration tests to utilize a temporary test directory for their workspace, ensuring isolated test runs.
• Resource Cleanup: Implemented automatic cleanup of the temporary test directory after all tests have completed, preventing orphaned files like .gitignore and .geminiignore from being left behind.
• Issue Resolution: Fixed the issue where sandbox manager integration tests were leaving behind .gitignore and .geminiignore files in the packages/core/ directory.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request updates the SandboxManager integration tests to use a temporary directory for the workspace, improving test isolation and ensuring proper cleanup. A critical issue was identified in the test skipping logic: because the manager is initialized within a beforeAll block, it remains undefined during the test discovery phase when the skip condition is evaluated. This prevents the tests from being correctly skipped on unsupported platforms.

[gemini-code-assist]

The current implementation of shouldSkip as a function called during test suite discovery (line 167) will always see manager as undefined because beforeAll has not yet executed. This causes the instanceof checks to evaluate to false regardless of the actual manager type, meaning the test suite will not be skipped even when using a NoopSandboxManager or LocalSandboxManager. This can lead to test failures in environments where sandboxing is not supported or disabled.

Since createSandboxManager and fs.mkdtempSync are synchronous and necessary for determining whether to skip the suite, they should be initialized at the describe block level. This ensures the skip condition is correctly evaluated while still using a temporary directory for the tests.

  const workspace = fs.mkdtempSync(path.join(os.tmpdir(), 'sandbox-integration-'));
  const manager: SandboxManager = createSandboxManager({ enabled: true }, { workspace });

  afterAll(() => {
    if (workspace && fs.existsSync(workspace)) {
      fs.rmSync(workspace, { recursive: true, force: true });
    }
  });

  // Skip if we are on an unsupported platform or if it's a NoopSandboxManager
  const shouldSkip =
    manager instanceof NoopSandboxManager ||
    manager instanceof LocalSandboxManager ||
    !ensureSandboxAvailable();

  describe.skipIf(shouldSkip)('Cross-platform Sandbox Behavior', () => {

References

1. For test environment setup, it is acceptable to use synchronous operations (e.g., fs.*Sync, execSync) within an async function. This approach is preferred for its simplicity and readability when the setup is sequential and not a performance bottleneck.
2. When creating temporary files or directories in global temporary directories (e.g., /tmp), use fs.mkdtempSync() to generate securely named, uniquely named temporary directories. This mitigates symlink attacks where an attacker could pre-create a symlink with a predictable name to truncate arbitrary files.