feat(api-proxy): forward COPILOT_INTEGRATION_ID from host env#4828
Closed
anticomputer wants to merge 2 commits into
Closed
feat(api-proxy): forward COPILOT_INTEGRATION_ID from host env#4828anticomputer wants to merge 2 commits into
anticomputer wants to merge 2 commits into
Conversation
External callers using AWF as a network firewall + auth proxy currently cannot set their own Copilot-Integration-Id: the api-proxy unconditionally rewrites the header from env.COPILOT_INTEGRATION_ID (defaulting to AWF's own 'agentic-workflows' tag), and the CLI wrapper does not forward this variable to the api-proxy container. This means every request the api-proxy emits is attributed to AWF on the upstream provider's side, even when the underlying caller is a distinct product with its own identity (and, in some cases, its own model allowlist). The caller has no way to opt out short of patching AWF. Mirror the existing GITHUB_API_URL / GITHUB_SERVER_URL pattern and forward COPILOT_INTEGRATION_ID to the api-proxy container when (and only when) the host env explicitly sets it. Default behaviour is unchanged: unset on the host -> not set on api-proxy -> falls back to the api-proxy built-in default. Tests added: - forward COPILOT_INTEGRATION_ID when explicitly set on host env - do NOT set on api-proxy when host env var is empty string (The existing 'do not forward GITHUB_COPILOT_INTEGRATION_ID' tests continue to pass -- the gh-aw-prefixed variant is intentionally still stripped because that one is set by gh-aw for AWF's own bookkeeping.) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
Pull request overview
Note
Copilot was unable to run its full agentic suite in this review.
Updates the api-proxy sidecar configuration so a host-provided Copilot integration identifier can be forwarded, enabling external callers to attribute requests to their own integration ID when desired.
Changes:
- Forward
COPILOT_INTEGRATION_IDinto the api-proxy container environment when explicitly set on the host. - Add tests verifying forwarding behavior when set vs. when empty.
Show a summary per file
| File | Description |
|---|---|
| src/services/api-proxy-service-config.ts | Adds conditional forwarding of COPILOT_INTEGRATION_ID to api-proxy env configuration. |
| src/services/api-proxy-service-api-targets.test.ts | Adds test coverage for forwarding and non-forwarding of COPILOT_INTEGRATION_ID. |
Copilot's findings
Tip
Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
- Files reviewed: 2/2 changed files
- Comments generated: 2
Addresses review feedback on github#4828: 1. Whitespace-only env values (e.g. ' ') previously passed the truthiness check and would have been forwarded to api-proxy, overriding its default with a meaningless value. Trim before the check and trim the forwarded value so accidental whitespace is treated as unset. 2. The COPILOT_INTEGRATION_ID forwarding tests duplicated the manual process.env save/restore pattern across every it() block. Replace with beforeEach/afterEach scoped to the describe (snapshotting both GITHUB_COPILOT_INTEGRATION_ID and COPILOT_INTEGRATION_ID), and a tiny local proxyEnv() helper to remove the repeated generateDockerCompose boilerplate. Net effect: each test body is one or two lines. Two new tests cover the trim behaviour: - 'should not set COPILOT_INTEGRATION_ID when host env var is whitespace only' - 'should trim surrounding whitespace before forwarding' 58 tests in this file (was 56), all passing. Full src/services/ suite still has the single pre-existing failure in agent-volumes-mounts.test.ts that was present on main before this PR. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Collaborator
|
@anticomputer sorry we don't accept PRs. please file as an issue |
This was referenced Jun 12, 2026
fix(entrypoint): bind-mount passwd/group synthesis fallback for read-only /host/etc (ARC/DinD)
#4831
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Allow external callers using AWF as a network firewall + auth proxy to set their own
Copilot-Integration-Idon outbound Copilot API requests by forwarding theCOPILOT_INTEGRATION_IDenv var from the host process to the api-proxy container.Problem
The api-proxy unconditionally rewrites the
Copilot-Integration-Idheader fromenv.COPILOT_INTEGRATION_ID(defaulting to the api-proxy built-in, currentlyagentic-workflows). The CLI wrapper deliberately does not forwardCOPILOT_INTEGRATION_IDto the api-proxy container, so external callers have no way to opt out:Copilot-Integration-Idthe caller sends to the api-proxy is discarded.In our pipeline this surfaced as: every audit our taskflow agent runs is silently tagged as the api-proxy default integration ID, regardless of what our agent code requests. We discovered this while investigating dashboard attribution, and only afterwards realised the v0.25.46 -> v0.25.47 flip of the api-proxy default would have silently removed model access for any caller depending on the old default.
Change
Mirror the existing
GITHUB_API_URL/GITHUB_SERVER_URLforwarding pattern inapi-proxy-service-config.ts: forwardCOPILOT_INTEGRATION_IDfrom the host env to the api-proxy container when (and only when) it is explicitly set.Default behaviour is unchanged: unset on the host -> not set on api-proxy -> falls back to whatever default the api-proxy ships with.
The gh-aw-prefixed variant (
GITHUB_COPILOT_INTEGRATION_ID) is intentionally still stripped, because that one is set by gh-aw for AWF's own bookkeeping. Existing tests covering that strip-behaviour continue to pass.Tests
Two new tests under the existing
describe('COPILOT_INTEGRATION_ID forwarding')block inapi-proxy-service-api-targets.test.ts:COPILOT_INTEGRATION_IDto api-proxy when explicitly set on the hostFull
src/services/suite: 392 pass, 1 pre-existing unrelated failure on main (agent-volumes-mounts.test.ts-- reproduced before applying this change).tsc --noEmit: clean.eslint: no new warnings introduced.