officer 7d79cab95c look for a member's tea config where their home actually is
It read /home/<osUser>, which is not where an Officer member's home is. Theirs
is DATA_PATH/<email>/home — where provisionUserDirs puts it and what useradd
was given — so a member with a working tea login was told they had none, and
the settings page asked for a token they had already set.

osUserHome is the platform's own answer to that question, and the same one tea
itself gets when run as that account, so reading and running now agree about
the path.

Not a sudo problem: runAs was escalating correctly the whole time, into a
directory that does not exist on any install.
2026-08-19 12:27:58 +00:00
2026-08-19 08:48:31 +00:00

Gitea

Your own Gitea inside Officer — repositories, issues and pull requests, rendered as the real thing rather than a copy of it.

What you get

Gitea's own web interface, in an Officer panel. Not a reimplementation: the actual application, proxied through Officer so it stays signed in, with an open in a new tab button for anything the frame handles badly.

Requirements

A Gitea instance Officer can reach.

Setup

Install the plugin, open /gitea, and set the instance URL and an API token in the connection panel. Then sign in to Gitea inside the frame, once — the frame shows your Gitea account, not the owner's.

The stored token is used only for the small things around the frame. Everything you see in it is your own session.

For agents

This plugin ships an affordance: use plain git for clone, fetch, pull and push; use tea for pull requests, issues, comments and releases. tea is logged in as you, with your permissions.

Permissions

One permission, gitea, grantable per role like any other app permission. Each account reaches its own Gitea identity.

S
Description
Gitea in Officer — repositories, issues and pull requests
Readme
2.2 MiB
Languages
TypeScript 100%