Developer data protection
OpenAI
Review Codex repository access by location
Separate local filesystem access from hosted repository access. Local Codex clients operate within the device’s effective permissions and configuration; Codex cloud uses a connected source system and a hosted checkout. Workspace access, repository grants and data handling are distinct decisions. Record the identities, repositories and execution locations actually approved.
For Enterprise AI and engineering-platform administrators
Identify the authorisation boundary before extending access.
Illustrative access paths and blank observations. No repository grant or product test is performed.01
Map the local repository path
For a local CLI or IDE client, identify the machine, operating-system account, workspace roots and effective permissions. A company repository may already be present on the device; that does not mean every local file is relevant to the task or approved for model context.
Record the permitted repository and task alongside the local control configuration. Keep credentials and private file contents out of the access worksheet. Use the separate local-secret guide for file-read and inherited-environment tests rather than making a repository-access review depend on real sensitive data.
Source context: OpenAI: Agent approvals and security
02
Map the hosted source-system grant
OpenAI’s enterprise setup guidance treats cloud access, the source-system integration, repository permissions and environment configuration as separate steps. Limit the source-system grant to the intended repositories and audience. A workspace seat is not an override of the connected repository’s permissions.
Codex cloud checks out a selected repository branch or commit into a hosted environment. Record the source-system identity and grant, the selected repository and the environment owner. The question is who can cause which code to be made available in that environment, not merely whether the product is enabled.
Source context: OpenAI: Enterprise admin setup · OpenAI: Cloud environments
03
Compare the two paths explicitly
Use a two-lane map so that a local approval is not silently reused for a hosted checkout. The local lane begins with files available on the device. The cloud lane begins with the connected source-system grant. Both can lead to code entering model context, but their access, administration and retained-record questions differ.
If a task moves between clients or locations, review the destination boundary before moving restricted material. A screenshot of a repository name is not enough: record the actual authorisation and the owner who can change it.
| Boundary | Local client | Hosted cloud task |
|---|---|---|
| Code source | Local accessible workspace | Connected repository checkout |
| Primary access evidence | Device identity, roots and permissions | Source-system integration and grant |
| Execution owner | Device/client administrator | Cloud environment administrator |
| Data handling | Client/provider and local records | Hosted environment and applicable workspace terms |
04
Record the records created by the task
Identify the relevant conversation, task artefacts and source-system records. OpenAI’s administrative guidance notes that connected services retain their own access, logging and retention requirements. A task’s workspace policy should not be treated as deletion or permission evidence for every external system.
Keep setup secrets and agent-phase variables out of this worksheet’s detailed procedure; they have their own guide. Here, record the environment owner and whether its data-handling review is complete. Unknown retention or access fields should stay unresolved rather than being filled from a different client’s settings.
Source context: OpenAI: Enterprise admin setup · OpenAI: Enterprise Work admin FAQ
05
Approve and periodically recheck the grant
Test the intended access with a representative authorised user and a synthetic repository or otherwise approved non-sensitive code. Confirm the expected repository is available and unrelated repositories are not part of the grant. Do not broaden access simply to make the test succeed.
Close with a named audience, repository scope, location, purpose and owner. Recheck after integration, group membership, repository ownership or environment changes. Record access removal and retained-data review separately when a tool or user is retired; revoking a grant is not proof that all earlier copies were deleted.
Source context: OpenAI: Enterprise admin setup
Put it into practice
Local and cloud repository-access worksheet
Record where code comes from, which identity authorises access and who owns the resulting records.
Illustrative access paths and blank observations. No repository grant or product test is performed.
Local path
Device identity → accessible workspace → local client
Review roots and permissions
Hosted path
Source-system grant → selected checkout → cloud environment
Review repository and audience
Shared review
Code context → model handling and task records
Confirm the applicable terms
| Path | Authorisation to verify | Observation |
|---|---|---|
| Local workspace | Device identity and effective roots | Untested |
| Hosted checkout | Source-system grant and selected repository | Untested |
| Task records | Applicable workspace/provider handling | Unreviewed |
| External source system | Its own access and retained records | Unreviewed |
Work through your review
Use the checks to organise the evidence you need. Save your selections in Word, then add your notes and evidence. Your selections stay in this tab until you download them.
0 of 3 reviewed
Examples and review material
Read the detail here, or keep the PDF, editable Word document and spreadsheets together.
Codex repository-access reviewRead
This pack creates no repository, grant, cloud environment or network call. Use synthetic repository labels until the responsible administrator records approved non-secret details.
Complete local-cloud-access.csv and the “Repository access decision” section. Use a representative authorised user to verify any actual grant through the organisation’s normal process. Do not paste tokens or broaden repository access to fill a worksheet row. Setup/agent-phase secrets are reviewed separately in D16.
Guide and sources
Canonical guide: https://aona.ai/resources/guides/codex-local-cloud-repository-access/ Source review: 2026-09-21
- OpenAI: Agent approvals and security: https://learn.chatgpt.com/docs/agent-approvals-security
- OpenAI: Enterprise admin setup: https://learn.chatgpt.com/docs/enterprise/admin-setup
- OpenAI: Cloud environments: https://learn.chatgpt.com/docs/environments/cloud-environment
- OpenAI: Enterprise Work admin FAQ: https://learn.chatgpt.com/docs/enterprise/work-admin-faq
Local cloud accessRead
| Boundary | Local path | Cloud path | Evidence | Owner | Status |
|---|---|---|---|---|---|
| Identity | RECORD DEVICE ACCOUNT | RECORD SOURCE-SYSTEM IDENTITY | ASSIGN | UNVERIFIED | |
| Repository | RECORD WORKSPACE | RECORD SELECTED REPOSITORY | ASSIGN | UNVERIFIED | |
| Audience | RECORD LOCAL ACCESS | RECORD GRANTED USERS OR GROUPS | ASSIGN | UNVERIFIED | |
| Authorisation | RECORD EFFECTIVE ROOTS | RECORD INTEGRATION AND GRANT | ASSIGN | UNVERIFIED | |
| Execution | RECORD DEVICE | RECORD HOSTED ENVIRONMENT | ASSIGN | UNVERIFIED | |
| Task records | RECORD HANDLING | RECORD HANDLING | ASSIGN | UNREVIEWED | |
| External records | RECORD IF APPLICABLE | RECORD SOURCE-SYSTEM HANDLING | ASSIGN | UNREVIEWED |
Repository access decisionRead
Illustrative repository: SYNTHETIC_REPO_ONLY Approved audience: ____________________ Local or hosted execution: ____________________ Repository/workspace scope: ____________________ Identity and grant evidence: ____________________ Representative access check: UNTESTED Data-handling owner: ____________________ Unresolved questions: ____________________ Decision: NOT YET REVIEWED Recheck after integration, group, repository or environment changes.
Before you proceed
Keep these distinctions clear
- Equating a workspace seat with repository permission
- Check the connected source-system grant and the repository’s own protections.
- Treating revoked access as deleted history
- Review earlier task records and external retained copies through their separate owners.
Apply it to employee AI use
Bring your actual data path.
Aona secures employees’ AI use on supported, installed endpoint paths.
An installed laptop endpoint does not establish protection of a vendor-hosted checkout. No agentless cloud enforcement is implied.
Bring the local path and a synthetic task to a scoped endpoint evaluation; keep hosted access with its environment owner.
Review your use caseFAQ
Questions for this decision
Does a Codex workspace seat grant access to every repository?
Does approving local Codex also approve Codex cloud?
Does this worksheet configure repository permissions?
Where should we review setup credentials?
Evidence behind the guide
Sources and scope
Prepared by Aona. Sources checked 2026-09-21. The cited material supports the specific points below; it does not certify a product or your use case.
- OpenAI: Agent approvals and security
Explains local sandbox and approval boundaries.
vendor · checked 2026-09-21 - OpenAI: Enterprise admin setup
Separates workspace, source-system grant, repository permission and environment administration.
vendor · checked 2026-09-21 - OpenAI: Cloud environments
Describes hosted repository checkout and task execution.
vendor · checked 2026-09-21 - OpenAI: Enterprise Work admin FAQ
Explains workspace and connected-service access/data-handling distinctions.
vendor · checked 2026-09-21