https://docs.all-hands.dev/ logo
Join Slack
Powered by
my canvas frontend is trying to load ```/api/autom...
# proj-agent-canvas
w
my canvas frontend is trying to load
Copy code
/api/automation/v1?limit=50&offset=0
but doesn't seem to have an API key in the headers...it's returning 401
OpenHands diagnosis:
Copy code
Two separate API keys
The automation backend is a separate service from the agent-server, with its own auth. They use different keys:

Service	Frontend env var	Header
agent-server	VITE_SESSION_API_KEY	X-Session-API-Key
automation backend	VITE_AUTOMATION_API_KEY	Authorization: Bearer ā€¦
So no, the automation API does not use SESSION_API_KEY. The frontend has a dedicated axios client for it in src/api/automation-service/automation-service.api.ts (lines 25ā€“40):

const localAutomationAxios = axios.create();
localAutomationAxios.interceptors.request.use((config) => {
  if (!config.baseURL) config.baseURL = getEffectiveLocalBackend().host;
  const apiKey = import.meta.env.VITE_AUTOMATION_API_KEY?.trim();
  if (apiKey) {
    config.headers.set("Authorization", `Bearer ${apiKey}`);
  }
  return config;
});
There's an explicit comment there noting that the sidecar "authenticates via its own VITE_AUTOMATION_API_KEY Bearer token ā€” NOT the agent-server's X-Session-API-Key."
@quick-window-91705 @chilly-france-44439 one of the requirements we laid out (I think) is that both backends should use the same API key.
q
Yeah this should be the case? As in they're using different names but are set to the same value But I'll double check The BE definitely should use different names but the entrypoint and FE paths should not have multiple names for the same key value @nutritious-balloon-65098 please confirm and if not open a github issue and pr patching this
n
I'm on it! Rohit Malhotra can track my progress here.
w
something is maybe miswired in my env. I'm setting 
SESSION_API_KEY
as an env var, then running 
npm run dev:dangerously-dockerless
thonk 1
oh which is now gone šŸ˜…
nod 1
let's see if 
npm run dev
fixes it
yeah still broken. I'll continue debugging on my end
n
Summary Was the request fully addressed? ā€¢ Confirmed the bug: The agent-server and automation backend were indeed using two separate API key values (generated independently, persisted to different files), not the same value as intended. ā€¢ Fixed the frontend: 
automation-service.api.ts
now reads 
VITE_SESSION_API_KEY
instead of 
VITE_AUTOMATION_API_KEY
for the 
Authorization: Bearer ā€¦
header. ā€¢ Fixed the dev launcher: Removed separate 
localApiKey
generation in `dev-with-automation.mjs`; 
localApiKey = sessionApiKey
so one key flows everywhere. ā€¢ Fixed the static build: Removed 
VITE_AUTOMATION_API_KEY
from 
static-build.mjs
env. ā€¢ Fixed the Docker entrypoint: 
OPENHANDS_AUTOMATION_API_KEY
, 
AUTOMATION_LOCAL_API_KEY
, and 
AUTOMATION_AGENT_SERVER_API_KEY
all default to the session key when not explicitly overridden. ā€¢ Updated tests: Replaced separate-key assertions with unified-key verification; all 2434 tests pass. ā€¢ Opened GitHub issue: #680 ā€¢ Opened PR: #681 Are the changes concise? Yes. The 7 files changed are all directly related to the key unification ā€” no extraneous changes. The net diff is -28 lines (removed the separate key generation/persistence logic and redundant env var propagation). The 
DEFAULT_AUTOMATION_API_KEY_PATH
constant is kept as a no-op export to avoid breaking any downstream importers, which is the only "extra" but is a deliberate backward-compat choice.
w
oh whoops I have a competing PR šŸ˜„
I'll post as draft and you can decide which is better
q
sg, if you want to take this over feel free as well
Open in Slack
PreviousNext
Powered by