If you temporarily disable og_workbench and it's still happening, you have a bigger problem. Was OG upgraded from 1.x -> 2.x?
I've found myself in this situation a few times during og upgrades. First, check to make sure all the OG Migrations have been run at admin/content/migrate. There is a migration named OgMigrateRoles that is often 0 of 0. Even though there is nothing to migrate, it still needs to run. If you do that and you still don't have access, check admin/config/group/permissions/node/[OG-ENABLED-CONTENT-TYPE]
You should see 3 columns w/ checkboxes for roles... NON-MEMBER, MEMBER, and ADMINISTRATOR MEMBER. If you see the rows permissions, but no checkboxes or roles your og_role table may be "hosed" for lack of a more technical term.
It is possible to manually repair this table by inserting rows for the 3 default roles for each of your og enabled content types. Something like...
INSERT INTO og_role (rid, gid, name, group_type, group_bundle) VALUES
(1, 0, 'non-member', 'node', 'group'),
(2, 0, 'member', 'node', 'group'),
(3, 0, 'administrator member', 'node', 'group');
The rid must be unique and 'group' should be replaced by your og enabled content type's machine name. Trying to manually repair the table isn't recommended and should only be used if you can't re-install... and even then only if you know your way around MySQL and on a test version of the site.
The good news is I've always been able to fix this with enough time and comparing the hosed og to a working OG2 install.