Jonathanfishner

jonathan from OneCLI here, yes - approval binds to the exact req by opening it (method, URL, body) when there’s a matching policy defined. then the gateway holds the call and the card shows the parsed payload.

just to clarify how it works - on same host, rules match based on method + path + body, not only the host. for example, GET /calendar/v3/* can be allowed while POST needs approval.

thats cool. n1. spent 15min looking on it rn

got it. we have not heard that need from users yet, but, can def see it being usefule as a fallback mechanism, since we are already sit at this network proxy layer.

what type of calls are you aiming to? can share example of that "call is billed.." is that specific apps you have in mind?

thanks, both are useful.

1. we support OAuth apps today, and we're growing the catalog based on demand. we support rotating and refreshing tokens for those.

2. I'd like to understand your case better. sitting in the request path means we could own retry mechanisms, but I'm curious what made you think of it, what kind of use cases did you have in mind?

yes the agent controls its environment which is exactly why nothing sensitive should live there. The gateway and the real secrets sit outside the sandbox. that said, not holding the secrets doesn't make the agent harmless. It still acts autonomously, and it can use whatever access those credentials grant. do you see the second half as the bigger risk? curious how people are thinking about it.

Creator of OneCLI here.

On (1), the agent runs in its own container where OneCLI doesn't exist. It can't spin up OneCLI or access its process because it's completely isolated from it. The agent only ever sees placeholder tokens, the real secrets live in a separate container it has no way to reach.

On (2), we actually address this with OneCLI Rules, deterministic constraints enforced at the proxy level before a request ever hits the API. So the agent doesn't need to "behave", it just can't do what the rules don't allow. Would love to hear more about your signed tokens approach.

that's exactly the idea. appreciate you framing it so clearly

Re IronClaw is probably the most hardened open-source implementation I've seen for this, but a sufficiently clever prompt injection against the built-in tools (especially shell) could still reach secrets.

Re TLS: OneCLI itself runs in a separate container, acting as an HTTPS proxy. The SDK auto-configures agent containers with proxy env vars + a local CA cert. When the agent hits an intercepted domain, OneCLI terminates TLS, swaps placeholder tokens for real creds, and forwards upstream. Containers never touch actual keys.

More here: https://www.onecli.sh/docs/sdks/node#how-it-works

Re 1Password adapters: not yet, but on the roadmap.

It's not the same. The core overlap is that agents shouldn't be holding raw credentials, that part isn't new, agreed. But the problem space goes further when you're building for agents specifically:

- Requiring human approval before sensitive actions go through (as @guyb3 mentioned in the post)

- Managing short-lived JWT tokens (refresh/access) with tight TTLs.

- Scoping permissions per-session rather than per-service

Auth-proxying solves the "don't give the box your API key" part. But the approval layer and token lifecycle management are what make this agent-specific, not just "SSO proxy repackaged."

i have 34 more minutes to edit this post, give me something good and i'll change it

We’re building ChartDB - an open-source tool to visualize and edit your database schema.

Supports Postgres, MySQL, SQLite, MSSQL, ClickHouse. Includes AI export to generate DDL in any SQL dialect.

17.5k+ GitHub stars, Feedback welcome!

https://github.com/chartdb/chartdb https://www.chartdb.io

Really interesting to see this built on Google Apps Script such an underrated gem for quick, reliable automations! Cal.com is already out there and doing great, but it’s still cool to see this lightweight approach. Sometimes simpler is just better, especially for folks who don’t need a full setup and just want a scheduling tool that ties right into Gmail.

It may be early, but great job putting it out there! Appreciate seeing alternatives that keep things lean and accessible-nice work!

Thank you for the kind words! I'm glad you're enjoying ChartDB. We appreciate your feedback about handling large tables with 100+ columns. Improving that experience is definitely on our radar! It would be great if you could open an issue on our GitHub repo with more details, that way, we can ensure it gets the attention it deserves and make it even better for your use case. Looking forward to your input!

Thanks for catching that! I’ve fixed it for you here: https://dbfiddle.uk/F2vuGKVS. I also tested the export script with a table name like "table", and it worked. If you don’t mind, could you open an issue in our repo? I’ll work on pushing a full fix today.

Thanks for giving it a try! I just tested it on an RDS PostgreSQL 15.4 instance, and it worked on my end. Would you mind opening a GitHub issue so we can dig into this further and help resolve it? Your input will be really helpful in fixing the issue.

Thanks for pointing that out! Just to clarify, we provide a single, hardcoded query that fetches metadata, with no option for user input. The user only needs to take the generated JSON and use it in a React app that they can also run locally. Since there's no user input involved, SQL injection shouldn't be a concern here. If you see any specific risks, though, I’d love to hear more!

Thank you for catching that issue with the STRING_AGG limit! I just pushed a fix that now supports nvarchar(max) to avoid truncation. This should resolve the issue with large outputs in MSSQL. If you still encounter any problems, please let me know. I'd love for you to give it another try and see if everything works as expected now. Your feedback is invaluable!

Thanks for the feedback! The emphasis on a single query highlights how easy it is to import your database schema: just run the query, get the JSON output, and start editing your diagram in ChartDB. Plus, there’s no need to sign in or set your database credentials. It’s all about simplifying the process and saving time so you can get started quickly. Speed is a bonus, but the main value is the simplicity and ease of use. Glad you're giving it a try!

Thank you first of all! ChartDB stands out with its one-query for visualization, AI-powered migration for easy cross-DB transitions, and interactive editing, all free and open-source, combining these features in a user-friendly way.

Thanks for the feedback! We aimed to make database migration easier and found that AI could really enhance this process by handling the complexities of different DB dialects. We'll also explore more deterministic approaches, as you suggested, using a common internal representation. The "Examples" link is being fixed—thanks for catching that!

Thank you! We use GPT-4o to generate database schema creation scripts for different database dialects. Basically, we wanted to add the option to export the db schema to any type of database (for easy Migration for example from MySQL to PostgreSQL or from SQLite to MariaDB). First, we tried to implement that logic, after getting into trouble with too many different edge cases and dialect differences between different databases we decided to leverage AI in order to achieve that.