DaVinci Resolve – Photo

Backblaze has stopped backing up OneDrive and Dropbox folders and maybe others

A new spam policy for “back button hijacking”

jj – the CLI for Jujutsu

Lean proved this program correct; then I found a bug

Rare concert recordings are landing on the Internet Archive

The future of everything is lies, I guess: Work

Introspective Diffusion Language Models

Spain to expand internet blocks to tennis, golf, movies broadcasting times

Distributed DuckDB Instance

Franklin's bad ads for Apple II clones and the beloved impersonator they depict

The M×N problem of tool calling and open-source models

Claude Code Routines

The exponential curve behind open source backlogs

5NF and Database Design

The acyclic e-graph: Cranelift's mid-end optimizer

We built the Kontext CLI because AI coding agents need access to GitHub, Stripe, databases, and dozens of other services — and right now most teams handle this by copy-pasting long-lived API keys into .env files, or the actual chat interface, whilst hoping for the best.The problem isn&#x27;t just secret sprawl. It&#x27;s that there&#x27;s no lineage of access. You don&#x27;t know which developer launched which agent, what it accessed, or whether it should have been allowed to. The moment you hand raw credentials to a process, you&#x27;ve lost the ability to enforce policy, audit access, or rotate without pain. The credential is the authorization, and that&#x27;s fundamentally broken when autonomous agents are making hundreds of API calls per session.Kontext takes a different approach. You declare what credentials a project needs in a .env.kontext file:<pre><code> GITHUB_TOKEN={{kontext:github}}
 STRIPE_KEY={{kontext:stripe}}
 LINEAR_TOKEN={{kontext:linear}}
</code></pre>
Then run `kontext start --agent claude`. The CLI authenticates you via OIDC, and for each placeholder: if the service supports OAuth, it exchanges the placeholder for a short-lived access token via RFC 8693 token exchange; for static API keys, the backend injects the credential directly into the agent&#x27;s runtime environment. Either way, secrets exist only in memory during the session — never written to disk on your machine. Every tool call is streamed for audit as the agent runs.The closest analogy is a Security Token Service (STS): you authenticate once, and the backend mints short-lived, scoped credentials on-the-fly — except unlike a classical STS, we hold the upstream secrets, so nothing long-lived ever reaches the agent. The backend holds your OAuth refresh tokens and API keys; the CLI never sees them. It gets back short-lived access tokens scoped to the session.What the CLI captures for every tool call: what the agent tried to do, what happened, whether it was allowed, and who did it — attributed to a user, session, and org.Install with one command: `brew install kontext-dev&#x2F;tap&#x2F;kontext`The CLI is written in Go (~5ms hook overhead per tool call), uses ConnectRPC for backend communication, and stores auth in the system keyring. Works with Claude Code today, Codex support coming soon.We&#x27;re working on server-side policy enforcement next — the infrastructure for allow&#x2F;deny decisions on every tool call is already wired, we just need to close the loop so tool calls can also be rejected.We&#x27;d love feedback on the approach. Especially curious: how are teams handling credential management for AI agents today? Are you just pasting env vars into the agent chat, or have you found something better?GitHub: <a href="https:&#x2F;&#x2F;github.com&#x2F;kontext-dev&#x2F;kontext-cli" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;kontext-dev&#x2F;kontext-cli</a>
Site: <a href="https:&#x2F;&#x2F;kontext.security" rel="nofollow">https:&#x2F;&#x2F;kontext.security</a>

Show HN: Kontext CLI – Credential broker for AI coding agents in Go

Let's Talk Space Toilets

Some technical context on what we ran into building this.MCP tools don&#x27;t really work for financial data at scale. One tool call for five years of daily prices dumps tens of thousands of tokens into the context window. And data vendors pack dozens of tools into a single MCP server, schemas alone can eat 50k+ tokens before the agent does anything useful. So we auto-generate typed Python modules from the MCP schemas at workspace init and upload them into the sandbox. The agent just imports them like a normal library. Only a one-line summary per server stays in the prompt. We have around 80 tools across our servers and the prompt cost is the same whether a server has 3 tools or 30. This part isn&#x27;t finance-specific, it works with any MCP server.The other big thing was making research actually persist across sessions. Most agents treat a single deliverable (a PDF, a spreadsheet) as the end goal. In investing that&#x27;s day one. You update the model when earnings drop, re-run comps when a competitor reports, keep layering new analysis on old. But try doing that across agent sessions, files don&#x27;t carry over, you re-paste context every time. So we built everything around workspaces. Each one maps to a persistent sandbox, one per research goal. The agent maintains its own memory file with findings and a file index that gets re-read before every LLM call. Come back a week later, start a new thread, it picks up where it left off.We also wanted the agent to have real domain context the way Claude Code has codebase context. Portfolio, watchlist, risk tolerance, financial data sources, all injected into every call. Existing AI investing platforms have some of that but nothing close to what a proper agent harness can do. We wanted both and couldn&#x27;t find it, so we built it and open-sourced the whole thing.

Show HN: LangAlpha – what if Claude Code was built for Wall Street?

The Fediverse deserves a dumb graphical client