Add Code Interpreter support for Gemini

[Benjamin-Sayaque]

Context

PR #71 added Code Interpreter support for OpenAI in the Chat class: activation through enableCodeInterpreter(containerId?), OpenAI payload construction, generated-file metadata extraction, container file download support, and public helper methods.

The goal is to extend the same capability to Gemini so that Gemini-based chat workflows can also execute code and expose generated artifacts where the Gemini API supports it.

Goal

Add Code Interpreter support for Gemini while keeping the existing public Chat API as consistent as possible with the OpenAI implementation:

• enableCodeInterpreter(containerId?)
• getGeneratedFiles()
• downloadGeneratedFile(fileIdOrIndex) when Gemini exposes downloadable generated files or an equivalent artifact mechanism
• getContainerId() or a documented Gemini-specific equivalent if the concept exists

Technical notes

• Identify the Gemini payload format required to enable Code Interpreter.
• Update Gemini payload construction so the tool is included when _codeInterpreterEnabled is enabled.
• Handle Gemini/OpenAI differences, such as container IDs, file citation formats, generated artifact metadata, and download endpoints.
• Extend response parsing so Gemini-generated files or artifacts are collected without changing existing OpenAI behavior.
• Update JSDoc/documentation if behavior differs by provider.
• Add Gemini-specific test helpers similar to the OpenAI helpers added in PR Add Code Interpreter tooling and generated file download support #71, for example Excel/PDF workflows if supported.

Acceptance criteria

• A Gemini chat can call enableCodeInterpreter() without errors.
• The Gemini request payload includes Code Interpreter correctly when enabled.
• Gemini-generated files or artifacts are exposed through getGeneratedFiles() when supported by the API.
• Downloading or retrieving Gemini artifacts is supported when the API allows it, or the limitation is clearly documented.
• Existing OpenAI Code Interpreter behavior remains unchanged.
• Test helpers or Apps Script tests are available to validate the Gemini flow.

Reference

Reference PR: #71, which implemented the OpenAI-side Code Interpreter support.

[coderabbitai]

🔗 Related PRs

#18 - Adds file-ingestion support so a user can upload a document or image,… [merged]
#27 - Update Gemini authentication to use header and improve endpoint handling [merged]
#51 - Add Gemini 3 to GenAIApp [merged]
#71 - Add Code Interpreter tooling and generated file download support [merged]
#83 - Add Gemini authentication-mode test entrypoint and README docs [closed]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[aubrypaul]

@coderabbitai plan this for codex

[coderabbitai]

Coding Plan

Summary

• Enable Gemini Code Execution by adding { code_execution: {} } to Gemini payload when _codeInterpreterEnabled is true
• Store Gemini inline artifacts directly in _generatedFiles with their base64 data, using structure detection to differentiate from OpenAI entries
• Adapt public methods (downloadGeneratedFile, getContainerId) to handle both providers seamlessly using the existing model.includes("gemini") branching pattern
• Add Gemini-specific test helpers following the standalone test pattern used for OpenAI Code Interpreter tests

Design Choices

Design Choice 1: How Gemini-generated artifacts should be stored in `_generatedFiles`

Options Considered:

1. Store Gemini artifacts with {mimeType, data, filename} alongside OpenAI's {containerId, fileId, filename} and detect provider by structure
2. Add a provider field to all entries and normalize the structure
3. Store Gemini blobs separately in a different array

Chosen Option: 1

Rationale: Store provider-specific structures and detect by presence of containerId vs data field. This minimizes changes to existing OpenAI behavior and keeps the implementation simple.

Design Choice 2: How `downloadGeneratedFile()` should handle Gemini artifacts

Options Considered:

1. Return the stored blob directly without an API call
2. Throw an error explaining Gemini doesn't support download (artifacts already available)

Chosen Option: 1

Rationale: Return a Blob created from the stored inline data. This provides a consistent API surface where downloadGeneratedFile() always returns a Blob, regardless of provider.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Enable Code Execution in Gemini Payload

Add support for the Gemini code_execution tool in the payload builder when code interpreter is enabled.

Add Code Execution Tool to Gemini Payload

Add the Gemini code_execution tool when _codeInterpreterEnabled is true.

• Modify _buildGeminiPayload() in src/code.gs to check this._codeInterpreterEnabled
• When enabled, push { code_execution: {} } to payload.tools array, following the existing pattern used for url_context and google_search
• The containerId parameter should be ignored for Gemini since Gemini Code Execution is stateless (no container concept)

🤖 Prompt for AI agents

Implement the Gemini code execution tool injection in the payload builder. The
goal is to enable the `code_execution` tool when `_codeInterpreterEnabled` is
true.

- In `src/code.gs`, locate `_buildGeminiPayload()`
- Add a check for `this._codeInterpreterEnabled`
- When true, push `{ code_execution: {} }` into the `payload.tools` array
- Follow the same pattern already used when adding `url_context` and
`google_search` tools
- Note: the `containerId` parameter has no equivalent in Gemini (stateless), so
it should be ignored for Gemini models

Phase 2: Parse and Expose Gemini Artifacts

Add helper methods and update existing public methods to extract, store, and serve Gemini inline artifacts from code execution responses.

Task 1: Extract Inline Artifacts from Gemini Response

Create a helper to parse Gemini responses for generated output files.

• Add a new method _extractGeminiInlineArtifacts(responseMessage) in src/code.gs near the existing _extractContainerFileCitations() method
• Scan responseMessage.parts for entries containing inlineData that represent outputs (images, files produced by code execution)
• Return an array of objects with {mimeType, data, filename} where filename is auto-generated (e.g., artifact_0.png) based on mime type
• Filter out inlineData that might be echoed inputs by checking for new artifacts in the response

Task 2: Integrate Artifact Extraction into Response Handling

Call the new extraction method during Gemini response processing.

• In the run() method of src/code.gs, after receiving a Gemini response, check if code execution was enabled
• Call _extractGeminiInlineArtifacts() and append results to this._generatedFiles
• This should mirror the existing pattern where OpenAI file citations are extracted and stored after each API call

Task 3: Update downloadGeneratedFile for Gemini

Adapt the download method to handle Gemini's inline artifacts.

• Modify downloadGeneratedFile(fileIdOrIndex) in src/code.gs to detect artifact type by checking for presence of data vs containerId
• For Gemini artifacts (those with data field): create and return a Blob from the stored base64 data and mimeType
• For OpenAI artifacts: continue using the existing _downloadContainerFile() API call
• Handle both index-based and identifier-based lookups appropriately for each provider

Task 4: Update getContainerId for Gemini

Ensure the method returns appropriate values for Gemini.

• Modify getContainerId() in src/code.gs to return null when using a Gemini model
• Add a provider check using the existing model.includes("gemini") pattern
• For OpenAI, preserve the existing behavior (return container ID from various sources)

🤖 Prompt for AI agents

Implement parsing, storage, and retrieval of Gemini inline artifacts across
several methods in `src/code.gs`. The goal is to make generated files from
Gemini code execution accessible through the existing public API.

**1. Add `_extractGeminiInlineArtifacts(responseMessage)`** (place near
`_extractContainerFileCitations()`):
- Scan `responseMessage.parts` for entries containing `inlineData`
- Auto-generate filenames (e.g., `artifact_0.png`) based on mime type
- Return an array of `{mimeType, data, filename}` objects
- Filter out any echoed input `inlineData` — only include new output artifacts

**2. Update `run()` method:**
- After receiving a Gemini response, check if `_codeInterpreterEnabled` is true
- Call `_extractGeminiInlineArtifacts()` on the response and append results to
`this._generatedFiles`
- Mirror the existing pattern used for OpenAI file citation extraction

**3. Update `downloadGeneratedFile(fileIdOrIndex)`:**
- Detect artifact type by presence of `data` field (Gemini) vs `containerId`
field (OpenAI)
- For Gemini artifacts: construct and return a Blob from the stored base64
`data` and `mimeType`
- For OpenAI artifacts: retain existing `_downloadContainerFile()` call
- Support both index-based and identifier-based lookups for each provider

**4. Update `getContainerId()`:**
- Add a check using `model.includes("gemini")` at the top of the method
- Return `null` for Gemini models
- Preserve all existing OpenAI behavior unchanged

Phase 3: Documentation and Testing

Update JSDoc comments for provider-specific behavioral differences and add Gemini Code Execution test functions.

Task 1: Update JSDoc for Provider-Specific Behavior

Document behavioral differences between OpenAI and Gemini Code Interpreter.

• Update JSDoc for enableCodeInterpreter() to note that containerId parameter is ignored for Gemini
• Update JSDoc for getContainerId() to document it returns null for Gemini (no container concept)
• Update JSDoc for getGeneratedFiles() to note different return structures by provider
• Update JSDoc for downloadGeneratedFile() to explain that Gemini files are returned from memory while OpenAI requires an API call

Task 2: Add Gemini Code Execution Test Helper

Create test functions to validate Gemini Code Execution flow.

• Add testGeminiCodeExecution() function in src/testFunctions.gs as a standalone Gemini-only test
• Test should enable code execution, send a prompt requiring computation (e.g., math calculation or data manipulation), and verify response
• Verify getGeneratedFiles() returns expected structure for any artifacts produced
• If artifacts are generated, verify downloadGeneratedFile() returns a valid Blob

Task 3: Add Gemini Code Execution with Artifact Test

Test artifact generation and retrieval when Gemini produces output files.

• Add testGeminiCodeExecutionWithArtifact() in src/testFunctions.gs
• Prompt should request something that produces an artifact (e.g., "generate a simple bar chart image")
• Verify artifacts appear in getGeneratedFiles() with correct structure (mimeType, data, filename)
• Verify downloadGeneratedFile() returns a Blob with correct mime type
• Optionally save to Drive and log URL similar to OpenAI tests

Task 4: Update testAll Entry Point

Register new test functions in the test runner.

• Add calls to new Gemini Code Execution test functions in testAll() in src/testFunctions.gs
• Follow existing pattern where tests are called unconditionally or guarded by configuration constants

🤖 Prompt for AI agents

Update JSDoc comments in `src/code.gs` and add new test functions in
`src/testFunctions.gs` to cover Gemini Code Execution. The goal is to document
provider-specific behavior and validate the full Gemini code execution flow.

**JSDoc updates in `src/code.gs`:**
- `enableCodeInterpreter()`: Note that the `containerId` parameter is ignored
for Gemini models
- `getContainerId()`: Document that it returns `null` for Gemini (no container
concept)
- `getGeneratedFiles()`: Note that return structures differ by provider
(`{mimeType, data, filename}` for Gemini vs `{containerId, fileId, filename}`
for OpenAI)
- `downloadGeneratedFile()`: Explain that Gemini files are returned from
in-memory data while OpenAI requires an API call

**New test functions in `src/testFunctions.gs`:**

1. `testGeminiCodeExecution()` — standalone Gemini-only test:
- Enable code execution, send a computation prompt (e.g., math or data
manipulation)
   - Verify response is returned
   - Check `getGeneratedFiles()` structure for any produced artifacts
   - If artifacts exist, verify `downloadGeneratedFile()` returns a valid Blob

2. `testGeminiCodeExecutionWithArtifact()` — artifact generation test:
   - Prompt Gemini to produce an output file (e.g., a bar chart image)
- Assert artifacts in `getGeneratedFiles()` have `mimeType`, `data`, and
`filename` fields
   - Assert `downloadGeneratedFile()` returns a Blob with correct mime type
- Optionally save the artifact to Drive and log the URL, following the OpenAI
test pattern

3. Register both new functions in `testAll()` following the existing call
pattern

Research

The project is a Google Apps Script library (GenAIApp) providing a unified Chat class that supports both OpenAI and Gemini models. Provider differentiation is handled via model.includes("gemini") checks throughout the codebase. The Chat class uses a closure pattern with private state variables and public methods. OpenAI Code Interpreter support was added in PR #71, which included payload injection in _buildOpenAIPayload(), response parsing via _extractContainerFileCitations(), and file download via _downloadContainerFile(). Gemini tools are added via payload.tools.push({...}) with different structures than OpenAI. Test functions use runTestAcrossModels() for cross-provider testing and standalone functions for provider-specific features.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Implement the Gemini code execution tool injection in the payload builder. The
goal is to enable the `code_execution` tool when `_codeInterpreterEnabled` is
true.

- In `src/code.gs`, locate `_buildGeminiPayload()`
- Add a check for `this._codeInterpreterEnabled`
- When true, push `{ code_execution: {} }` into the `payload.tools` array
- Follow the same pattern already used when adding `url_context` and
`google_search` tools
- Note: the `containerId` parameter has no equivalent in Gemini (stateless), so
it should be ignored for Gemini models
===============================================================================

Task: 2

Implement parsing, storage, and retrieval of Gemini inline artifacts across
several methods in `src/code.gs`. The goal is to make generated files from
Gemini code execution accessible through the existing public API.

**1. Add `_extractGeminiInlineArtifacts(responseMessage)`** (place near
`_extractContainerFileCitations()`):
- Scan `responseMessage.parts` for entries containing `inlineData`
- Auto-generate filenames (e.g., `artifact_0.png`) based on mime type
- Return an array of `{mimeType, data, filename}` objects
- Filter out any echoed input `inlineData` — only include new output artifacts

**2. Update `run()` method:**
- After receiving a Gemini response, check if `_codeInterpreterEnabled` is true
- Call `_extractGeminiInlineArtifacts()` on the response and append results to
`this._generatedFiles`
- Mirror the existing pattern used for OpenAI file citation extraction

**3. Update `downloadGeneratedFile(fileIdOrIndex)`:**
- Detect artifact type by presence of `data` field (Gemini) vs `containerId`
field (OpenAI)
- For Gemini artifacts: construct and return a Blob from the stored base64
`data` and `mimeType`
- For OpenAI artifacts: retain existing `_downloadContainerFile()` call
- Support both index-based and identifier-based lookups for each provider

**4. Update `getContainerId()`:**
- Add a check using `model.includes("gemini")` at the top of the method
- Return `null` for Gemini models
- Preserve all existing OpenAI behavior unchanged
===============================================================================

Task: 3

Update JSDoc comments in `src/code.gs` and add new test functions in
`src/testFunctions.gs` to cover Gemini Code Execution. The goal is to document
provider-specific behavior and validate the full Gemini code execution flow.

**JSDoc updates in `src/code.gs`:**
- `enableCodeInterpreter()`: Note that the `containerId` parameter is ignored
for Gemini models
- `getContainerId()`: Document that it returns `null` for Gemini (no container
concept)
- `getGeneratedFiles()`: Note that return structures differ by provider
(`{mimeType, data, filename}` for Gemini vs `{containerId, fileId, filename}`
for OpenAI)
- `downloadGeneratedFile()`: Explain that Gemini files are returned from
in-memory data while OpenAI requires an API call

**New test functions in `src/testFunctions.gs`:**

1. `testGeminiCodeExecution()` — standalone Gemini-only test:
- Enable code execution, send a computation prompt (e.g., math or data
manipulation)
   - Verify response is returned
   - Check `getGeneratedFiles()` structure for any produced artifacts
   - If artifacts exist, verify `downloadGeneratedFile()` returns a valid Blob

2. `testGeminiCodeExecutionWithArtifact()` — artifact generation test:
   - Prompt Gemini to produce an output file (e.g., a bar chart image)
- Assert artifacts in `getGeneratedFiles()` have `mimeType`, `data`, and
`filename` fields
   - Assert `downloadGeneratedFile()` returns a Blob with correct mime type
- Optionally save the artifact to Drive and log the URL, following the OpenAI
test pattern

3. Register both new functions in `testAll()` following the existing call
pattern

💡 Iterate on the plan with: `@coderabbitai` <feedback>

Example Feedback
- `@coderabbitai` You can skip phase 3. Add a simple unit test case for phase 2.
- `@coderabbitai` For design choice 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!