feat: relayauth integration — JWKS verification + path-scoped access

[khaliqgant]

Summary

Adds workflow (workflows/integrate-relayauth.ts) to integrate relayauth into relayfile:

• Go server: verify relayauth JWTs via JWKS endpoint
• Path-scoped access: relayfile:fs:write:/src/api/* restricts file writes to matching paths
• Mount daemon: accepts relayauth tokens via existing --token flag
• TS SDK: fromRelayAuth() factory for relayauth-authenticated clients
• Backwards compatible — existing relayfile JWTs still work

Depends on

• @relayauth/sdk types (for token format reference)
• Go JWKS verification (standard library, no external deps)

Run

agent-relay run workflows/integrate-relayauth.ts

🤖 Generated with Claude Code

---

[devin-ai-integration]

Devin Review found 2 potential issues.

View 7 additional findings in Devin Review.

[devin-ai-integration]

🔴 Tar export sends HTTP 200 before writing, making error responses impossible

writeTarExport calls w.WriteHeader(http.StatusOK) at internal/httpapi/server.go:2033 before writing tar entries. If tw.WriteHeader or tw.Write fails afterward (lines 2047-2051), the error is returned to handleExport at internal/httpapi/server.go:1429-1430, which calls writeError with status 500. However, since WriteHeader(200) was already called, Go's HTTP server silently ignores the second WriteHeader(500) call. The client receives a truncated/corrupt tar file with a 200 OK status, making the failure invisible to the caller.

Prompt for agents

In internal/httpapi/server.go, the handleExport function at line 1428-1431 calls writeTarExport which sends a 200 OK header before writing tar content. If tar writing fails after that, the writeError call at line 1430 has no effect because the status code was already sent. Fix this by having writeTarExport decode all content BEFORE calling WriteHeader, so that decoding errors can still produce proper error responses. For write errors that occur during streaming (after WriteHeader), either log the error and let the truncated response signal failure to the client, or buffer the entire tar in memory before writing (trading memory for correctness). Remove the writeError call at line 1430 since it cannot meaningfully change the response after WriteHeader was already called inside writeTarExport.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🟡 normalizeEncoding returns "utf-8" for empty input, making omitempty on File.Encoding ineffective

normalizeEncoding("") returns "utf-8" at internal/relayfile/store.go:3690-3691. This value is stored in File.Encoding (which has json:"encoding,omitempty" at line 76). Because the returned value is non-empty, omitempty never triggers, so every file written via WriteFile or BulkWrite — including plain text files where the caller did not specify encoding — will have "encoding": "utf-8" in JSON responses. Meanwhile, provider-synced files explicitly set Encoding: "" at internal/relayfile/store.go:3259, so they omit the field. This creates an inconsistency: the same text file has different JSON shapes depending on whether it was written by an agent or synced from a provider. The fix is to return "" (empty string) instead of "utf-8" for the default case, letting omitempty omit the field for text files.

Suggested change

	case "", "utf-8", "utf8":
	return "utf-8", nil
	case "", "utf-8", "utf8":
	return "", nil

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[khaliqgant]

Review: relayauth integration (relayfile)

Verdict: Needs changes before merge

This PR bundles ~6 distinct features. Key issues:

Critical/High

1. Misleading title — no actual JWKS code; relayauth is only a workflow definition. Should split into focused PRs.
2. Hardcoded local paths in workflow files.
3. Duplicate release workflows — both trigger on v* tags creating races.
4. Potential deadlock in syncer mutex discipline.
5. Silent event dropping with no logging.

Medium

6. No bulk write size limits enforced (despite design doc claims).
7. WebSocket token in query params (security consideration).
8. Homebrew formula has placeholder SHA256s.
9. README references old SDK path.

Missing Tests

• CLI tool: 940 lines, zero test coverage.
• No tests for bulk write limits, WebSocket reconnection.

[devin-ai-integration]

Devin Review found 1 new potential issue.

View 10 additional findings in Devin Review.

[devin-ai-integration]

🟡 CLI seed prints all progress messages instantly before the bulk upload even starts

The runSeed function at lines 434-436 uses a for i := range files loop that simply iterates over the already-collected files slice and prints "Seeding X/Y files..." for each one. This loop completes instantly before the single bulk API call at line 439. The user sees all progress lines (e.g. "Seeding 1/100", "Seeding 2/100", ..., "Seeding 100/100") dumped at once, then a pause while the actual upload happens. The loop should either be removed (since all files are sent in one request) or the progress should be tied to actual batched uploads.

Suggested change

	for i := range files {
	fmt.Fprintf(stdout, "Seeding %d/%d files...\n", i+1, len(files))
	}
	fmt.Fprintf(stdout, "Seeding %d files...\n", len(files))

---

Was this helpful? React with 👍 or 👎 to provide feedback.