didericis/bot-bottle
1
0
Fork 0
Code Issues 7 Pull Requests 15 Actions Packages Projects Releases Wiki Activity

PRD 0030: Deduplicate egress token resolution across backends #119

Merged
didericis merged 5 commits from prd-0030 into main 2026-06-02 00:59:05 -04:00
Conversation 7 Commits 5 Files Changed 7
+173 -41
didericis-claude commented 2026-06-02 00:26:33 -04:00
Collaborator
Copy Link
Copy Source

Closes #118.

PRD: 8c2b59ca94/docs/prds/0030-deduplicate-egress-token-resolution.md

Summary

  • Extracts the duplicated forward_host_credentials / CODEX_HOST_CREDENTIAL_TOKEN_REF resolution block from both backend launch files into a single egress_resolve_token_values_with_provider in bot_bottle/egress.py
  • Fixes the incorrect host_env: object annotation on smolmachines._resolve_token_env to dict[str, str]
  • Removes now-unused imports from both backends

Changes (3 commits)

  • 6682357 docs(prd): add PRD 0030
  • 75f0f9d refactor(egress): deduplicate token resolution across backends
  • 8c2b59c complete(prd): mark PRD 0030 active
Closes #118. PRD: https://gitea.dideric.is/didericis/bot-bottle/src/commit/8c2b59ca949550cf9eef34321660fe7db56d9334/docs/prds/0030-deduplicate-egress-token-resolution.md ## Summary - Extracts the duplicated `forward_host_credentials` / `CODEX_HOST_CREDENTIAL_TOKEN_REF` resolution block from both backend launch files into a single `egress_resolve_token_values_with_provider` in `bot_bottle/egress.py` - Fixes the incorrect `host_env: object` annotation on `smolmachines._resolve_token_env` to `dict[str, str]` - Removes now-unused imports from both backends ## Changes (3 commits) - [`6682357`](https://gitea.dideric.is/didericis/bot-bottle/src/commit/6682357fbb3973443c2001deb71674c838725afa/docs/prds/0030-deduplicate-egress-token-resolution.md) `docs(prd): add PRD 0030` - [`75f0f9d`](https://gitea.dideric.is/didericis/bot-bottle/src/commit/75f0f9d90783c2a61e1ec595e697edbf83cb13ff/bot_bottle/egress.py) `refactor(egress): deduplicate token resolution across backends` - [`8c2b59c`](https://gitea.dideric.is/didericis/bot-bottle/src/commit/8c2b59ca949550cf9eef34321660fe7db56d9334/docs/prds/0030-deduplicate-egress-token-resolution.md) `complete(prd): mark PRD 0030 active`
didericis-claude added 3 commits 2026-06-02 00:26:36 -04:00
docs(prd): add PRD 0030 — deduplicate egress token resolution 6682357fbb 
Extracts the forward_host_credentials / CODEX_HOST_CREDENTIAL_TOKEN_REF
resolution block, currently copy-pasted in both docker and smolmachines
launch files, into a single shared function in bot_bottle/egress.py.

Closes #118. Found via #117 hotspot review.
refactor(egress): deduplicate token resolution across backends (PRD 0030) 75f0f9d907 
Extract egress_resolve_token_values_with_provider into bot_bottle/egress.py.
Both docker and smolmachines launch paths now call the shared function
instead of duplicating the forward_host_credentials / CODEX_HOST_CREDENTIAL_TOKEN_REF
resolution block.

Also fixes the host_env: object annotation on smolmachines._resolve_token_env
to the correct dict[str, str].

Closes #118.
complete(prd): mark PRD 0030 active
test / unit (push) Successful in 45s
Details
test / integration (push) Successful in 1m0s
Details
test / unit (pull_request) Successful in 39s
Details
test / integration (pull_request) Successful in 58s
Details
8c2b59ca94
didericis reviewed 2026-06-02 00:32:42 -04:00
didericis-claude reviewed 2026-06-02 00:34:23 -04:00
didericis-claude reviewed 2026-06-02 00:37:26 -04:00
didericis-claude commented 2026-06-02 00:39:45 -04:00
Author
Collaborator
Copy Link
Copy Source

Why isn't the codex access token just put in the token_env_map in the agent provider logic for codex?

The reason CODEX_HOST_CREDENTIAL_TOKEN_REF exists as a sentinel is that egress_resolve_token_values assumes every token_ref is an operator-set host env var it can look up in host_env, and dies if it's missing. The Codex access token isn't in the operator's env; it's parsed out of ~/.codex/auth.json at launch time. Without the sentinel, egress_resolve_token_values would hit the "env var unset" die for that slot.

That said, the implicit suggestion is sound: instead of skipping the ref in egress_resolve_token_values and post-processing in egress_resolve_token_values_with_provider, we could pre-populate a copy of host_env with the Codex token value under the sentinel key before calling egress_resolve_token_values — then that function stays fully generic and the skip goes away. The codex_host_access_token() call would still live in egress_resolve_token_values_with_provider, so the external shape is the same. Want me to refactor along those lines?

> Why isn't the codex access token just put in the token_env_map in the agent provider logic for codex? The reason `CODEX_HOST_CREDENTIAL_TOKEN_REF` exists as a sentinel is that `egress_resolve_token_values` assumes every `token_ref` is an operator-set host env var it can look up in `host_env`, and dies if it's missing. The Codex access token isn't in the operator's env; it's parsed out of `~/.codex/auth.json` at launch time. Without the sentinel, `egress_resolve_token_values` would hit the "env var unset" die for that slot. That said, the implicit suggestion is sound: instead of skipping the ref in `egress_resolve_token_values` and post-processing in `egress_resolve_token_values_with_provider`, we could pre-populate a copy of `host_env` with the Codex token value under the sentinel key *before* calling `egress_resolve_token_values` — then that function stays fully generic and the skip goes away. The `codex_host_access_token()` call would still live in `egress_resolve_token_values_with_provider`, so the external shape is the same. Want me to refactor along those lines?
didericis commented 2026-06-02 00:45:06 -04:00
Owner
Copy Link
Copy Source

RE #119 (comment)

No, I'd like you to pass down a provisioned_env instead. Construct that map during provisioning steps, and merge it with the host env (have the provisioned env override the host env). That we we can keep codex specific provisioning things together.

RE https://gitea.dideric.is/didericis/bot-bottle/pulls/119#issuecomment-994 No, I'd like you to pass down a `provisioned_env` instead. Construct that map during provisioning steps, and merge it with the host env (have the provisioned env override the host env). That we we can keep codex specific provisioning things together.
didericis-claude commented 2026-06-02 00:48:33 -04:00
Author
Collaborator
Copy Link
Copy Source

RE #119 (comment)

Good call — the sentinel skip was a code smell. Here is the revised plan:

  • Add provisioned_env: dict[str, str] (default empty) to AgentProvisionPlan.
  • In agent_provision_plan, when forward_host_credentials=True for Codex, call codex_host_access_token(host_env) and store {CODEX_HOST_CREDENTIAL_TOKEN_REF: <value>} in provisioned_env. This is already the prepare-time stage where write_codex_dummy_auth_file runs, so the access-token read is colocated with all other Codex-specific provisioning.
  • In both backends, replace the call to egress_resolve_token_values_with_provider with: egress_resolve_token_values(plan.egress_plan.token_env_map, {**dict(os.environ), **plan.agent_provision.provisioned_env}).
  • Delete egress_resolve_token_values_with_provider and remove the CODEX_HOST_CREDENTIAL_TOKEN_REF sentinel skip from egress_resolve_token_values. The function becomes fully generic again.

Implementing now.

RE https://gitea.dideric.is/didericis/bot-bottle/pulls/119#issuecomment-995 Good call — the sentinel skip was a code smell. Here is the revised plan: - Add `provisioned_env: dict[str, str]` (default empty) to `AgentProvisionPlan`. - In `agent_provision_plan`, when `forward_host_credentials=True` for Codex, call `codex_host_access_token(host_env)` and store `{CODEX_HOST_CREDENTIAL_TOKEN_REF: <value>}` in `provisioned_env`. This is already the prepare-time stage where `write_codex_dummy_auth_file` runs, so the access-token read is colocated with all other Codex-specific provisioning. - In both backends, replace the call to `egress_resolve_token_values_with_provider` with: `egress_resolve_token_values(plan.egress_plan.token_env_map, {**dict(os.environ), **plan.agent_provision.provisioned_env})`. - Delete `egress_resolve_token_values_with_provider` and remove the `CODEX_HOST_CREDENTIAL_TOKEN_REF` sentinel skip from `egress_resolve_token_values`. The function becomes fully generic again. Implementing now.
didericis added 1 commit 2026-06-02 00:53:32 -04:00
refactor(egress): use provisioned_env instead of sentinel for Codex token (PRD 0030)
test / unit (pull_request) Successful in 39s
Details
test / integration (pull_request) Successful in 45s
Details
0e29bcc829 
Add `provisioned_env: dict[str, str]` to `AgentProvisionPlan`. When
`forward_host_credentials=True`, `agent_provision_plan` reads the host
Codex access token at prepare time and stores it under
`CODEX_HOST_CREDENTIAL_TOKEN_REF`. Both backends merge `provisioned_env`
over `os.environ` before calling `egress_resolve_token_values`, so the
token slot resolves like any other manifest-declared token ref.

Removes `egress_resolve_token_values_with_provider` and the sentinel
`continue` skip from `egress_resolve_token_values`. The function is now
fully generic — it neither knows nor cares about provider identity.
didericis added 1 commit 2026-06-02 00:54:16 -04:00
docs(prd): update PRD 0030 design to reflect provisioned_env approach
test / unit (pull_request) Successful in 33s
Details
test / integration (pull_request) Successful in 45s
Details
test / unit (push) Successful in 31s
Details
test / integration (push) Successful in 43s
Details
e528d5c5af 
Revises the Design section to describe the implemented solution:
provisioned_env on AgentProvisionPlan rather than an intermediate
egress_resolve_token_values_with_provider function. Drops the old
sentinel/lazy-import design narrative.
didericis approved these changes 2026-06-02 00:58:59 -04:00
didericis merged commit e528d5c5af into main 2026-06-02 00:59:05 -04:00
didericis deleted branch prd-0030 2026-06-02 00:59:06 -04:00
Sign in to join this conversation.
Reviewers
No Reviewers
didericis-claude
didericis
Labels
Clear labels
Compat/Breaking
Breaking change that won't be backward compatible
 Kind/Bug
Something is not working
 Kind/Documentation
Documentation changes
 Kind/Enhancement
Improve existing functionality
 Kind/Feature
New functionality
 Kind/Security
This is security issue
 Kind/Testing
Issue or pull request related to testing
Priority
Critical
1
The priority is critical
Priority
High
2
The priority is high
Priority
Low
4
The priority is low
Priority
Medium
3
The priority is medium
Reviewed
Confirmed
1
Issue has been confirmed
Reviewed
Duplicate
2
This issue or pull request already exists
Reviewed
Invalid
3
Invalid issue
Reviewed
Won't Fix
3
This issue won't be fixed
Status
Abandoned
3
Somebody has started to work on this but abandoned work
Status
Blocked
1
Something is blocking this issue or pull request
Status
Need More Info
2
Feedback is required to reproduce issue or to continue work
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
didericis-claude (didericis (claude)) didericis-codex (didericis (codex)) didericis-gemma (gemma) didericis
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: didericis/bot-bottle#119
Delete Branch "prd-0030"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?