For ACP file-based authentification OpenHands/OpenHands in a cloud setting, I added a small utils: set a special secret env value. The SDK turns that value into a file that allows authentication. This does simplify OpenHands/OpenHands (no need to upload auth file anymore, just add a secret) but @chilly-france-44439 pointed out here that we do need file mounting anyway so it might not be worth it. Wdyt? @limited-student-10747

My main concern is that if we did implement something like this secret evn var, then we'd still have to support direct auth when we run a bare unsandboxed agent-server in a VM. Example usecase: https://github.com/OpenHands/agent-canvas/issues/348 This means if we do this

secret -> file

, we'd eventually have two authentication path for ACP, one using env var, and another one using files

will take a look

> https://openhands-ai.slack.com/archives/C06R25BT5B2/p1778873730130289?thread_ts=1778871892.168529&cid=C06R25BT5B2 wrt this - i think it depends on how our planned UX for this. e.g.: • We are just expecting the user to follow our guide, go to their keychain, copy the credential, and paste in the UI • OR we write a script that automatically access the keychain and get the credential on behalf of user Also, do we need to even need to do this, if we want ACP to run in a unsandboxed agent-server running locally -- and the local terminal's

claude

should already be authenticated?

I haven't looked at this carefully yet, but if we assume the easiest setting of agent-canvas and running locally unsandboxed, how hard is this to implement?

Agree on this, basically: • unsandboxed agent-server: user need to make sure

claude

is authenticated, then ACP should automatically work out of the box • sandboxed agent-server: we only support

ANTHROPIC_API_KEY

and

OPENAI_API_KEY

for now, which would be the easiest to do now WDYT?

> sandboxed agent-server: we only support

ANTHROPIC_API_KEY

and

OPENAI_API_KEY

for now, which would be the easiest to do now Claude Code actually exposes a secret for subscription authentication, so no file mounting is needed. It's more for Codex/Gemini. Agreed that for Canvas we can go with local simplest solutions as long as it doesn't cause problems for cloud later.

OK, yeah, I think we can proceed with a simple solution for now

> This means if we do this

secret -> file

, we'd eventually have two authentication path for ACP, one using env var, and another one using files (edited) In any case, we do need two auth methods for ACP: • subscription • api keys API keys is easy: same flow as openhands agent For subscription, Claude = API key. But for Codex and Gemini, subscription = auth file. So it seems like we do need to support both file mounting and env secrets for ACP auth. What this PR does and is helper in the SDK that takes a specific env variable and turns it into a file. This way, for agent-canvas / OpenHands, the code is much simpler. But in any we do need to mount files in the sandbox for conversations etc... so it's also OK to put that logic in the canvas. Edit: I guess I'll just start by having the canvas do it and we can always refactor later if it makes sense @chilly-france-44439 @limited-student-10747 lmk what you think

I guess I'll just start by having the canvas do it and we can always refactor later if it makes sense

nod Overall, I think it's probably more reasonable for the downstream application to handle these files rather than at the root SDK level. Canvas decides what other CLIs they need to support, and each of those might have different logic for subscription authentication.

@chilly-france-44439 I made a PR, it adds SDK support for ACP providers whose credentials must be read from files rather than plain env vars. Specifically, it materialises pasted credential blobs into durable per-conversation files, such as Codex’s CODEX_HOME/auth.json and Gemini Vertex’s GOOGLE_APPLICATION_CREDENTIALS, while keeping the raw blobs out of normal env injection and prompt secret advertisement. Then I asked opus and codex what they though about our conversation. Their recommendation is keeping the file writing in the SDK Concise arguments

1. The May-15 thread conflated two targets — local-unsandboxed (Xingyao right: SDK shouldn't materialise) vs cloud/Docker (the point of #988, where downstream can't reach the pod
  FS).
  2. Decisive constraint — in cloud the only channel into the pod is secret_registry; materialisation must run in-pod, and the env/persistence/seed-if-absent wiring is irreducibly
  SDK-side regardless.
  3. "Two auth paths" is intrinsic — Codex/Gemini subscription auth is file-based; moving it downstream relocates the path rather than removing it, and bypasses masking (#1023).
  4. The PR is already the hybrid the advice asked for — mechanism (SDK) vs overridable policy (ACPFileSecretSpec data) — and is a no-op locally, so the unsandboxed-VM case stays
  untouched.
  5. Recommendation: keep it SDK-side, with one genuinely open sub-decision flagged for them — openhands-sdk core vs openhands-agent-server (but explicitly not canvas).

opus https://github.com/OpenHands/agent-canvas/issues/1020#issuecomment-4612007648 codex https://github.com/OpenHands/agent-canvas/issues/1020#issuecomment-4612019039 Prompt used for review

Read this PR <https://github.com/OpenHands/software-agent-sdk/pull/3474>. Read the epic and issue linked to it and read the PR diff.
  Then read this conversation with the lead architect from my company
 <conversation>

  Should we change our strategy to follow his advice? Draw pros and cons. Be thorough.

Just a side note, I feel like we might return to this in cloud environment, because these are one per user, and maybe mounting locations with user-specific data in the sandbox helps for speed with cold (re)starts… I think we were discussing that somewhere 🤔