Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Enabling auth orphans pre-existing agents, collections and skills (root user bucket)

Aperta
  • Qualcosa non va?
#12,665 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
45/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
go
Ambito
authentication, backend

Direzione di ricerca

Start with core/services/agentpool/user_storage.go, where the empty user ID resolves to the base directory, then getUserID in core/http/endpoints/localai/agents.go. Step 1 is the narrowest first change: at startup, when auth is enabled and the root bucket holds agents, collections or skills, log a warning with the counts and a docs pointer. Steps 2 and 3 (admin listing, the LOCALAI_AUTH_LEGACY_OWNER migration) touch agent_pool.go and the collections and skills services, so they need maintainer direction first. Done means the warning appears in the logs in that state and not otherwise.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Is your feature request related to a problem? Please describe.

When an existing instance turns on LOCALAI_AUTH, everything that was created while auth was off stays in the
root bucket (userID == "") and becomes unreachable over the API — for every user, including admins.

What happens, per resource:

  • Agents. UserScopedStorage.resolve("") maps the empty user to the base directory
    (core/services/agentpool/user_storage.go), and with auth on every request carries a real user ID
    (getUserID in core/http/endpoints/localai/agents.go). GET /api/agents therefore never lists the legacy agents,
    and ?all_users=true does not include them either. The agents are still started by pool.StartAll(), but their
    LLM calls fail with 401 when their api_key is empty and LOCALAI_AGENT_POOL_API_KEY is unset. They keep running
    (including periodic_runs) without anyone being able to see, edit, pause or delete them.
  • Collections, skills / git repos, tasks / jobs, outputs. Same pattern: CollectionsBackendForUser,
    SkillsServiceForUser and the job service fall back to the root instance only for userID == "", so after the switch
    users get a fresh, empty users/<uid>/… area.
  • Agent state (character, scheduler state, long-term memory) has no API at all, so it cannot be exported before
    the switch either.

There is no startup message about it, and nothing in the docs says what happens to existing data. On our instance
(8 agents, about 100 collections, a few hundred thousand chunks) this would have looked like "all data gone" right
after enabling auth.

Reproduction (no models needed):

  1. Start LocalAI without auth, create an agent and a collection (POST /api/agents, POST /api/agents/collections).
  2. Restart with LOCALAI_AUTH=true and LOCALAI_ADMIN_EMAIL=<you>, register as that admin.
  3. GET /api/agents and GET /api/agents?all_users=true with the admin key: the agent is missing.
    GET /api/agents/collections: the collection is missing. The agent still shows up in the logs as running.

Related: re-creating the agents by hand under the admin works (POST /api/agents with the old config), but every
create or update without api_key auto-generates a new agent:<name> key that inherits the owner's role
(CreateAgentForUser / UpdateAgentForUser / ImportAgentForUser in core/services/agentpool/agent_pool.go). For a
migration done by an admin, that gives every migrated agent an admin-level key, and repeated updates pile up keys.
Passing an explicit api_key avoids both, but that is not obvious.

Describe the solution you'd like

Three steps, each useful on its own:

  1. Startup warning. When auth is enabled and the root bucket is not empty, log a warning with the number of root
    agents / collections / skills and a pointer to the docs. Cheap, and it turns a silent loss into a visible decision.
  2. Admin visibility of the root bucket. Show it to admins as an "unowned" group: ?all_users=true includes root
    agents and collections under a reserved owner (e.g. "" → "unowned"), the admin UI lists them, and admins can
    export (GET …/config, the existing agent export) and delete them. Read/export/delete only; no running as another
    user.
  3. Opt-in migration: LOCALAI_AUTH_LEGACY_OWNER=<email or user id>. On startup with auth on, move the root bucket
    once to that user's area (agents, collections, skills, tasks, outputs, agent state), write a marker so it never runs
    twice, and log what was moved. If the user does not exist yet, skip and warn. Agents moved this way keep an
    explicitly configured api_key; for empty ones the migration does not auto-generate an owner key but leaves
    them on LOCALAI_AGENT_POOL_API_KEY and warns, so a migration by an admin never mints admin-level agent keys.

Docs: a short section in the auth docs ("Enabling auth on an existing instance") covering the root bucket, the
bootstrap rule (the first registered user becomes admin, also in invite mode, unless LOCALAI_ADMIN_EMAIL is set),
the recommended order, and the api_key behaviour of agent create/update.

Describe alternatives you've considered

  • Re-create everything by hand under the admin via the API. That works for agent configs and lets us re-ingest
    collections, but agent state and long-term memory are lost, and it needs care with api_key (see above).
  • Keep auth off and put a reverse proxy with SSO in front. That's what we do today, but it gives no per-user
    separation inside LocalAI, which is the reason to use LOCALAI_AUTH in the first place.
  • Moving files on disk from the base directory to users/<uid>/ by hand. Possible, but it depends on internal layout
    details, so it is not something users should have to do.

Additional context

Found while testing a switch from an external UI to LocalAI's built-in auth on a copy of a production instance
(agent pool in LocalAGI mode). Happy to send a PR for step 1 (and the
docs) first, then 2 and 3 if the direction is fine with you.

AI-assisted draft (Claude Code), reviewed and submitted by the reporter.

Lingua principale
Go
Stelle
49.4k
Fork
4.5k
Merge medio
1g 22m
PR unite (30g)
387

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di mudler/LocalAI

Tutte le issue di mudler/LocalAI

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.