Long-running Worker Auth

[akoenig]

I have a question about the expected authentication lifecycle for a long-running Omnigent worker/host.

Setup

I deployed:

• The Omnigent platform/server on one machine
• An Omnigent worker/host on a separate machine

The worker is authenticated against the Omnigent platform first, then started as a long-running process.

Rough flow:

omnigent login https://<my-omnigent-server>
# then start the worker/host as a long-running process
omni host --server https://<my-omnigent-server>

After that, everything works correctly. Agents can be spawned and they connect back to the platform as expected.

Problem

The setup keeps working until the spawned agents have been idle for a while. When I come back after a couple of hours, the worker/host no longer seems to be authenticated properly, and I have to run omnigent login again on the worker machine before things work again.

I already tried increasing the account/session lifetime, for example:

OMNIGENT_ACCOUNTS_SESSION_TTL_HOURS=<larger value>

or the equivalent setting for my auth mode, but the worker still eventually requires re-authentication.

Expected Behavior

For a long-running worker/host process, I expected one of the following:

1. The worker remains authenticated across idle periods and reconnects automatically, as long as the configured session TTL has not expired.
2. Or, if the browser/user session cookie is not intended to be used for long-running workers, there is a documented service-token or worker-token flow for unattended hosts.
3. Or, if CLI-launched workers need specific environment credentials available so they can mint fresh bearer tokens on every reconnect, the required setup is documented clearly.

Actual Behavior

After the agents are idle for a few hours, the worker/host needs manual re-authentication with omnigent login before it can continue working.

Questions

• Is this expected behavior for a CLI-launched worker/host connected to an authenticated Omnigent server?
• Which lifetime controls worker/host authentication across idle periods and WebSocket reconnects?
  OMNIGENT_ACCOUNTS_SESSION_TTL_HOURS?
  OMNIGENT_OIDC_SESSION_TTL_HOURS?
• A separate host/runner tunnel token TTL?
• Something else?
• Is there a recommended way to run a worker/host unattended for days without interactive re-login?
• Should the worker be started with a separate service credential rather than relying on omnigent login?

Environment

I can provide exact values if useful, but the relevant shape is:

• Omnigent version (server and worker): 0.3.0
• Server deployment type: Docker
• Auth mode: OIDC
• Worker/host OS: Ubuntu 26.04 (both)

Thanks! I am trying to understand whether this is a configuration issue on my side, a missing long-running-worker auth flow, or a bug in the reconnect/auth refresh path.

[UnknownHawkins]

The worker authenticates with the same short‑lived access token that the CLI obtains during omnigent login.
That token is refreshed only when the CLI can call the token‑refresh endpoint, which requires a refresh token stored in the user’s login session (the browser‑style session cookie). Refresh tokens are deliberately kept short‑lived for security, and the server clears them after a few hours of inactivity. When the worker’s WebSocket reconnects after that period it presents an expired access token and the server rejects it, so you have to run omnigent login again.

For unattended hosts the recommended pattern is to use a service‑account token (or “host token”) instead of a user login. Create a service account in the Omnigent UI/CLI, export its token to the host machine, and start the host with:

export OMNIGENT_HOST_TOKEN=<service‑account‑jwt>
omni host --server https://<my-omnigent-server>

[akoenig]

Thanks @UnknownHawkins, that makes sense. Just to confirm: this isn’t available in 0.3.0, right? I couldn’t find an option for it in either the CLI or the UI.

[UnknownHawkins]

Yes, that's my understanding as well. I couldn't find any support for a dedicated service-account or host-token authentication flow in 0.3.0 neither in the CLI, the UI, nor the available documentation.

From what I can tell, omni host relies on the credentials established by omnigent login, so once the underlying OIDC authentication can no longer be refreshed, the host eventually requires another interactive login.

If that's the intended behavior in 0.3.0, then it seems the only current option is to periodically re-authenticate. Otherwise, it would be great to know if there's an undocumented mechanism for unattended hosts or if a non-interactive host/service authentication flow is planned for a future release.

[highoncomputers]

You're running into a session token lifecycle issue that's common with OIDC-authenticated worker architectures. Here's what's happening and how to fix it.

Root cause: The omnigent login command authenticates via OIDC and stores a session token (typically a JWT with an expiry). This token is used by the worker/host process to authenticate WebSocket reconnections and API calls to the Omnigent server. The session TTL you configured (OMNIGENT_ACCOUNTS_SESSION_TTL_HOURS) controls how long the session lives in the server's database, but the access token that the worker holds likely has a much shorter lifetime (often 1 hour by default in OIDC flows).

The worker process doesn't automatically refresh this token after the initial login, so when the access token expires, the worker can no longer authenticate its reconnection attempts.

The specific env vars you asked about:

• OMNIGENT_ACCOUNTS_SESSION_TTL_HOURS — Controls how long the session record persists on the server. If you set this to 72, the session lives for 3 days on the server side. But the worker's access token may still expire earlier.
• OMNIGENT_OIDC_SESSION_TTL_HOURS — Controls the OIDC provider session lifetime. This affects the browser-based login flow, not the worker's access token.

What's likely missing: The worker needs either: (a) automatic token refresh using a refresh token, or (b) a long-lived service token that doesn't expire.

Solutions (best first):

1. Use a service token / API token instead of OIDC login for workers — This is the recommended approach for unattended workers. Check if omnigent supports creating a service account token via omnigent token create or similar. Service tokens are designed for machine-to-machine auth and don't expire after hours of inactivity.

2. Set up a token refresh loop — If the worker CLI supports a --token flag or OMNIGENT_TOKEN env var, you can generate a token with a long TTL and pass it directly:

   export OMNIGENT_TOKEN=$(omnigent token create --ttl 720h)  # 30 days
   omni host --server https://<my-omnigent-server>

3. Wrap the worker with a restart-on-failure loop — If token refresh isn't supported, wrap the omni host command in a systemd service or supervisor that detects the auth failure and re-runs omnigent login + omni host.

For the Omnigent team to consider: A --service-account flag or OMNIGENT_WORKER_TOKEN env var that accepts a long-lived token specifically for worker auth would solve this cleanly. The current design assumes the login session stays alive, but long-running workers need a different auth primitive.

TL;DR: The session TTL settings affect server-side session lifetime, but your worker's access token likely expires sooner. Use a long-lived service/API token for the worker instead of relying on omnigent login.